One of the things that I love about consulting is that its a very two-way kind of thing. The consultant brings a lot of exposure to different technologies, software development patterns and first hand observations, and the client typically brings unique challenges, new and interesting team dynamics. Today I had a meeting with a client that reminded me why I still do this job.
We were discussing the shape of a possible consulting engagement where I would spend a day or more with their team looking at their particular problem, listening to how they were going to tackle it and suggesting some additional things that they might like to try. They are also in the throws of adopting Team Foundation Server and since that is one of my strengths we thought that we might throw in some time to look at how they were going to use that to change the culture of their software development organisation.
This kind of discussion interests me because I believe that building an effective software development organisation doesn’t need an overly complex and descriptive process, rather it needs good people and a simple set of rules.
As the set of rules grows and the agents (developers) execute on them, complex and behaviour emerges (emergent behaviour). Sometimes the outcome can be good, and sometimes the outcome can be bad – but the feedback will always result in the revision of that set of rules – just in the same way a child learns in an environment with consequences.
In a blog post last year I pointed to a post by Wesner Moise about intelligence and the material that he referenced from Stephen Wolfram. Stephen Wolfram published a book called “A New Kind of Science” in which (based on the reviews I have read) he argues that all complex systems are emergent behaviour of simple systems.
Over lunch time conversations with some of my colleagues I speculated that humanity is just cellular automata at a different scale (although I don’t think I put it that clearly) and if thats true and I wasn’t smoking weed, then a team of software developers governed by a set of simple rules could result in some truly amazing results (good or bad).
This kind of thinking isn’t new in the software space. Agile methodologies set out a set of core practices that team members adhere to, and guys like Adam Cogan run their businesses according to rules (although he calls them standards, they’re not).
When other software developers first work with me they will often find that I am extremely pedantic about certain things and that I can get quite shirty when things aren’t done precisely the way that were agreed. It is easy to dismiss my behavour as the mood swings of an irrational man, but the reality is that I am having a gut/emotional reaction to something that I know could leave to problems – “I don’t know why this is wrong, but just trust me it is”.
At some point in the future, if my suggestions are ignored I’ll get the chance to say I told you so, but it will be cold comfort because it is too baked in to be corrected. Tonight I decided, partially triggered by my discussions with a client today, to start documenting the a list of rules that I want developers on the projects I am working on to live by, the first rule?
- Every rule in this document can be changed except this one.
What I am saying is that I want the list of rules to be a living document that is ammended as needed, it will never be perfect but the simple rules will result (hopefully) in complex behavour that just seems to work. You can download my first software development rules here, there are only five in this cut.