I am deadly tired of all the buzz that we are suffering from. Our view on how software should be developed seems to change dramatically every second or third year, more frequently than the whims of fashion. Big companies around the world carelessly discard expensive process and tool investments, almost before they have even tried them. Instead of learning from experience they heedlessly start with something they believe is fundamentally new. In reality very little has changed. As in the fashion world, there is much ado about next to nothing. In something as trivial as clothing this may be acceptable, but with the size of our investment in software this is wasteful, expensive and absurd.
The latest trend is “being agile” (as exemplified by Scrum). The “agile” movement has reminded us that people matter first and foremost when developing software. This is not really new - this theme resurfaces every decade or so as naive managers try to mechanize and commoditize what is basically an exercise in creative problem solving. It is important that we not lose track of how to work as a team, how to collaborate, how to document what we do, and how to plan our work on daily, weekly, and monthly timescales, etc. But in bringing these things back to focus, much is lost or obscured by new terms for old things, creating the illusion of something completely new.
The result of this is a lot of wasted effort as old truths are rediscovered but cloaked in apparent new clothing. Younger and less experienced coworkers promote new trends, following new gurus, supported by the hype of a media always hungry for “news”. Managers who have lost touch with actual development find themselves in a hopeless situation: resist the newest fashion and they brand themselves as out of touch. Pilot projects are run to force proof of merit for the new approach, but motivated developers can make anything work on a small scale. As a result the new approach overtakes the old, and all that was working with the old approach is thrown out along with the parts that were not. Only too late do they discover that the new approach itself has parts that don’t work along with the parts that do.
At the root of this problem is a deep misunderstanding of the nature of software development. Researchers have tried to attack this problem with new theories like formalism to prove correctness of programs, or through formal languages which never have been adopted outside the academic world. Industry efforts have spent years standardizing swollen meta-models that defy easy understanding.
Universities and technical institutes teach us a particular way of working. Every project adopts a special method which we must first learn and master before we can begin to work. Every time we change jobs we have to learn a new approach before we can get on with the real task at hand. This is not effective; we cannot learn from experience as we are forever starting over.
We need to stop forever chasing after fads and easy answers that forever disappoint. But how? This is a problem I have thought about for at the least ten years and of course I have a concrete idea on how we can get there. However, I will have to wait to tell you that until my next blog. Let me however say this much: We need to start small and simple and keep it small and simple. We did so with SDL and UML. We can do it again.
That would be smart!