Not in code

Enjoy watching a nerd talk about software. (Thanks for the link Mat K)

Hooked? The video not enough? Need more now? Why not join the coolest group on Facebook.

Disclaimer: Very little thought, much emotion.

Q. What is the Liskov Substitution Principle?

A. I’ll tell you what it isn’t: throw new UnsupportedOperationException();

*Shudder*

Much of the agile software movement is about loosening controls, shifting more to asking forgiveness rather than permission. Yet loosening controls isn’t the same as anarchy and no control - a misrepresentation that’s commonly thrown at agilists too. It’s about asking how we can use a minimum of controls, so that that we don’t suffocate the good in our desire to protect ourselves from the bad.

From Martin Fowler’s Bliki: http://martinfowler.com/bliki/WikipediaDeath.html

In the Elements of Style, William Strunk describes one of his pricinples of composition Omit needless words by saying

A sentence should contain no unnecessary words, a paragraph no unnecessary sentences, for the same reason that a drawing should have no unnecessary lines and a machine no unnecessary parts.

These words resonate with me; I hold a similar view about how software should be written and as I read this book a number of its rules & principles seem to apply equally to writing good software. This makes sense since the majority^ of code we write is in English. It seems to me that every developer who aspires to be their best would do well to aquire this guide; so, I’ve added this book to my list of books every software developer should own.

^I recently discovered that most of SAP’s code is written in German.

I could tell straight away that I will enjoy learning about this topic! I relish opportunities to expand and enrich my vocabulary and already this course has introduced me to a few new concepts.

A couple that stand out as I recollect the first two lectures are the distinction between data, information and knowledge; and the classification of knowledge into explicit and tacit knowledge. Colin�s discussion of Generation Y was also intriguing, appealing even - I need to research this some more.

I agreed with his comments about the disconnect between IT and business, this is something that agile methods like eXtreme Programming (XP) recognise and work actively to address; in XP this is via the practice of an Onsite Customer. I am however curious to see how this relates to KM and if and how it is addressed.

A challenge I face professionally relates to the question of how to achieve effective knowledge transfer in a rapidly growing team. We have grown from ~8 to ~32 developers and several business analysts and testers in a short period. So far we have relied on the XP practice of Pair Programming and other forms of face-to-face communication while attempting to manipulate team structure and size by breaking into smaller sub-teams.

My own experience has been that informal, face-to-face communication is an excellent means of knowledge transfer when the team size is still small (5-10 people), however as the team grows so do the associated costs. I hope this course lends some clues about how to manage knowledge transfer in larger rapidly changing teams especially those that keep growing and where limiting this growth isn�t really an option.

What are the tools, techniques and principles that have worked for others? Why?

I also look forward to contrasting and comparing some of the views which have been and will be put forward with familiar values and principles of XP and the agile software development community. Colin made a comment about software development being composed of 80% explicit knowledge and 20% tacit knowledge when discussing the hybrid model. Many proponents of agile methods, including myself, would probably state the ratio differently with tacit knowledge being 80%. In fact many agilists, refer to themselves as craftsmen not engineers. I am curious to further explore the basis of his assertion as at least on the surface I feel it contradicts my own views.

Finally, I can tell that there will be plenty an opportunity to apply what I will learn in this course: at my current job, in my personal learning, and in future roles - particularly if (when) I succeed in my ambition of running my own software firm one day.