Software Development Success – With Spanners
There must be at least 7 other blog posts on the internet claiming to hold the secrets of software development success. Well, here it is, number 8.
One of the very few benefits of being an old git is that you’ve been doing the same thing for long enough to know that there is very little different as the software industry fuels itself with faddish changes of language, methodology and the feature porn fetish of the modern web world. (I still find it astonishing that the social media news world gets so excited by the addition of tiny features).
There are very few constants in all of this. The obvious ones are that software and training companies make money from continual and, often unnecessary, change. Another constant is that every year, the Standish Group’s Chaos Report suggests that a lot of software projects don’t go well. And software engineers constantly refuse to accept that their new shiny toy isn’t the solution to these issues…
“Blah, blah, blah but we’re using insert faddish methodology here writing in insert faddish language here”
We must always remember Cobb’s Paradox:
“We know why projects fail, we know how to prevent their failure – so why do they still fail?”
Very few people ever seem to take note of this. Why would they? Everyone wants to play with the newest shiny so saying it will make no difference is a tough sell.
There is a key central constant. Good people deliver good software entirely independently of what methodology and language they use.
And good people… are spanners.
Every lifecycle has embedded within in it some form of analysis, design, development and test. These things are obvious and discrete in a waterfall world, they are buried somewhere inside more fluid approaches – but still get done.
In the same way that people who know how the compiler works write better code and those that can code come up with better designs, people who can span the disciplines contribute more to the success of a project than those that stay in one box.
This is not just because multi-skilled people have, well, more skills. It is because software development is nothing more than an elaborate game of Chinese whispers. Every time you introduce a transition from one phase or one person to another you have an artefact (I didn’t say document, I’m modern) that intends to communicate the knowledge to that point. How well the recipient interprets that artefact determines how much of the original intent is lost. Spanners prevent information loss at these crucial transitions. They know enough about both the sending and receiving end to ensure that things are picked up and continue on the right path.
If you can span your way across all the work in the project then the perception gap between desire and deliverable is reduced. In effect, if you can get the clever dev guy to talk to the end user and just get on with it, y0u’ll have much more success than if you let the requirements pass through multiple hands, mouths, documents, whatever like some modern day version of Incan Chasquis.
This is why (I have to say this or the evangelista will get grumpy) agile/scrum stuff works. It’s not because the methodology itself necessarily makes the people doing it any better but they are at least required to get on the same page together and have smaller gaps of time before they check that they’re doing the right thing. At the end of a two week sprint the perception gap can only ever be two weeks wide at most. More traditional waterfall projects can idly spent months heading in the wrong direction.
Here’s the thing; when you are looking for new people, don’t let the job specs have too narrow a focus – you’re looking for people who can reach across the lifecycle. But don’t ask for spanners. That could go horribly wrong.