Flexibility, design and process

Software is, in theory, infinitely flexible. I can take the software from my toaster and, with enough modification, get it to run a nuclear power station. OK, I’d have to be pretty odd to want to do this, and one could argue whether it is the same software (does it pass the Mary Rose test?*) but you get my point.

(*The Mary Rose Test, the Mary Rose, is a wooden battleship from Henry VIII’s navy that is preserved in Portsmouth. Imagine I decide to renovate the ship, so every day I replace one of the aging planks of wood with an identical replacement. Now, further imagine that I use the planks I remove to build a copy of the Mary Rose. When I am finished which is the original? And at one point, if any, did it change?)

Much of software design is concerned with removing your flexibility: encapsulation, data hiding, cohesion. Sometimes you actually improve things by removing the option. (Less is more.)

The same is true in development processes. Often a company cries, “We need a flexible development process” because... we need to respond to anything a customer can throw at us, all our projects are different, etc. But I wonder how many of the organizations that say this actually do vary their process? In my experience companies like to say this but the only real variation that occurs is the number of people on the project. The actual project process is left vague and ill defined “for flexibility.”

If there really is no similarity in the projects that organizations do then I wonder if the organization really exists for a particular reason. What is the core competency if no two projects are the like? Far more likely there is similarity in some way.

So, what we need is to cut off some options to ourselves. I’m not saying we need to document our process - heaven forbid! Nor am I saying that we need to call in process experts to advice us on how to do the project. What I’m saying is we need some kind of process base line we can talk about, some reference point. For if we can’t talk about it we can’t describe it and can’t modify it. Within that we need to give ourselves some constraint, leaving all our options open makes for too much uncertainty.

With all that said its important to note that process must come from the bottom up. It is for the people who live and breath the process to decide what they are doing. That doesn’t mean they can’t be influenced in their decisions, nor does it mean they can’t be lead or challenged to do better. It may just boil down to showing them that things can be different and providing them with the tools and options to do it differently.

And when they find a better way of doing things the people above them should use their leadership to support it, and to help others see the benefits and change too.

The worst thing we can do is to just assume that tomorrow will be a repeat of today. We should ask teams to do better, to change, to improve but we should also give ourselves boundaries and rules to work within. And we should, from time to time, question those boundaries and rules.