Software Development Rules

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.

• File Attachment: Software Development Rules.doc (63 KB)

ConferenceXP

Matthew Cosier re-introduced me to ConferenceXP yesterday. Its a product of Microsoft Research which enables developers to plug in and build conferencing capabilities directly into their applications (sweet). I’d love to see some of these capabilities baked into Visual Studio to enable virtual development teams to keep in constant contact throughout the day (which means you still have to get dressed for work, even when you are working from home).

Paul, Geoff and Damian are the TechTalkBloggers!

Wow! Frank has chosen a grouptrio of bloggers to represent TechTalkBlogs in the lead up to TechEd 2006. Congratulations guys, I’ll have to watch what I say around you now – mind you, you were always bloggers and not afraid to spill the beans.

Daniel Moth on the “using” statement.

I love syntax posts, I love the syntax of programming languages because it often reveals common insights that language designers do or do not have when it comes to certain kinds of problems. One of the nice things about the using statement in C# is the way that you can nest them. For example:

using (Foo f = new Foo())
using (Arb a = new Arb())
using (Bar b = new Bar())
{
    // F A B, thunderbirds are go!
}

I call it nesting, but its not visually nested so the syntax is more compact. The Visual Basic implementation due to the VB code block syntax has a lot more visual noise. Its not a good reason for choosing one language over the other, you just need to train yourself to filter it out in VB, but subconsciously recognise the nesting in C#.

The Lying Media

Darren seems to have started a personal campaign against/for the mass media asking them to clean up what they are reporting. He has a point . . .

When I attended University of Queensland one of the majors that I was studying for was journalism. I managed to get through the first semester before changing subjects because I was so disgusted with the way that stories could be edited to be sensationalist rather than just conveying the facts – and it had nothing to do with the words you added, it had all to do with the facts that you omitted.

Television is time limited, and the newspaper is space limited so they need to trim the material down to make it fit, but the way you trim it down has a big impact on the way the audience consumes the material. Roy Osherove’s blog post about the Pallywood video is certainly thought provoking.