Well, bully for Tom – after years of thrusting structured approaches to developing software down our throats, in a recent article of his he’s now telling us to give up the details and go for the big idea behind the software. As if anyone has ever had time to do one or the other…
Successful software projects can be put down to a lot of factors, but the biggest one of them is luck – luck in having a good team, who know what they are doing and where they are going, and have fun getting there; luck in having management and the customer as part of that team and not as a hinderance; luck in not being underfunded, having enough time to do the job properly and being allowed to keep the team intact; luck in having a good idea in the first place. If you’ve got that much luck, you’re probably onto a good thing. Don’t you love that word “luck”? It could almost pass for the past tense of “lick.”
But he did mention one point which I liked, and that was the fact that development is experimental. This has given me an idea for a new movement in software development. I don’t think that “experimental” is quite the right word for it, I would rather call it a speculative endeavour in the true sense of the word. It’s got all the advantages you need to start up a new cult with – the name: Speculative Software Development; it’s appropriately vague and non-informative; has a multitude of meanings which the erstwhile developer can interpret for his/her own needs; has the taste of money making so that the management are happy; has the necessary philosophical depth so that the architects can bathe in the glow of its self-importance. Most importantly SSD has a short acronym with at least two S’s in it, so that project managers and team leaders can think that they are heading a crack, elite, alpha plus military task force, which makes up for not being able to play soldiers at home.
On the slightly more serious side, if people are looking for methods, or simply ways of working in development (and I’m not talking about SCRUM – that’s just a methodological framework – it’s what goes into it that’s important), then maybe they should start drawing analogies with how daily papers or magazines are produced, instead of thinking that development has anything to do with the building industry.
Why bring in such a metaphor? Because the techniques and work practices made available can deal with one of the factors which in previous methodologies has been largely ignored, namely that software development is a thoroughly creative activity. Now, you will often find developers moaning that their creativity is capped by this or that constraint, or managers who say that the last thing they want is a creative developer, but this simply shows a lack of understanding of what it means to work in a creative industry. I would argue that creative processes are as rigorous as most engineering processes, if not more so, (okay, I’m not counting going to the moon), but are always organised around individual and collective creative input at all levels, and allow the harnessing of inductive thought, as opposed to the simpler structuring of deductive thought.
Anyway, to cut a long story short, I think that Tom is probably right in signalling the death of software engineering, in that it has began to stifle the motivations behind software development, but people need to start looking for new metaphors and practices for organising their work which take into account the creative and speculative nature of development.
And now a toast to engineering. Long live software engineering!