Fashion is such a ridiculous business. Every year anorexic clothes horses strut up and down modelling ridiculous clothes no-one is ever going to wear. Hemlines go up or down. Various baubles are ‘in’ or ‘out’. Grey is the new black. We geeks are above all that. Comfortable in our jeans, bad haircuts and nerdily sloganed black t-shirts we know that #000000 != #0c0c0c . We care not a jot for fads and fashions. Or do we?

Actually, I think software development follows its own fads and fashions, just as slavishly as any Gucci-clad fashionista. Here are a few past and present software development ‘fashions’ that spring to mind:

• 3GLs
• 4GLs
• methodologies (SSADM, Yourdon etc)
• CASE tools
• object orientation
• UML
• Java
• XML
• extreme programming/agile methods
• Ruby on Rails

While all of these ideas contain something useful, they never turn out to be the panacea we were promised. Consequently they follow (or, I predict, will follow) an all-to-familiar boom and bust cycle:

1. potential – The technology appears to have some promise.
2. hype – The technology is wildly over-hyped. Massive and unrealistic increases in productivity are touted.
3. hysteria – Lots of books and magazine articles are written. Developers worry their careers will suffer if they don’t learn the new technology, and soon.
4. backlash – The reality falls far short of expectations and the whole worth of the technology is called into question. But actually the technology is improving as it matures.
5. realism – Expectations settle down to more realistic levels and the best elements of the technology are absorbed into mainstream practice.

We can visualise the cycle in a simple graph:

Java is a good example of this cycle. It started its life as Oak, a language for set-top boxes. Renamed to the more catchy Java and pushed by Sun as a write-once run-anywhere language it soon passed from hype to hysteria on a wave of coffee related puns. Everything would soon be written in Java we were told in endless gushing articles. The performance issues would be sorted out in the next release. Corel were rewriting their office suite in Java. Netscape were rewriting their browser in Java. C++ was finished. Sun’s stock rose meteorically.

In fact Java apps of the time were ugly and slow and the cross-platform capabilities turned out to be problematic. Write-once run anywhere became write-once, test everywhere. Java Corel office was rapidly abandoned when the beta was found to be completely unusable (I tried it myself, it was a joke). Netscape’s attempts to produce a web browser in Java also failed. The backlash began. In actual fact Java is now not much slower than C++ for many applications. But the Java zealots cried wolf so many times in the past that few people believe them any more. Finally we are reaching a realistic understanding of the strengths and limitations of Java, but most of us lost interest in Java a long time ago and are too busy pursuing the next ‘great thing’.

What is the latest fad? Agile methods is certainly a contender. Agile methods are ‘lightweight’ methodologies, a backlash against ‘heavyweight’ methodologies, such as Rational unified Method and SSADM. If you search for “agile” in ‘Books>Computers & Internet’ on Amazon.com you get 2,964 matches. How can so much possibly be written about a ‘lightweight’ approach? A recent C/C++ conference I went included no less than 6 talks with ‘agile’ in the title (and a couple more on the related topics of ‘lean development’ and ‘scrum’). No doubt there are whole conferences about agile methods. While I don’t doubt that an agile approach contains useful ideas, I very much doubt that it is a one-size-fits-all, ‘one true way’ to develop software. But you would be forgiven for thinking that it was if you listened to some of the agile zealots (especially the ‘extreme programming’ wing of the agile church).

Boom and bust is a painful, expensive and pathological way to adopt new ideas and technologies. Why can’t we take a more measured and mature approach? Fred Brooks warned us over 30 years ago that software development is hard and it probably always will be. But the message appears still not to have sunk in. We are still looking for for that mythical silver bullet. The problem is partly caused by many developers having a lack of perspective. They are so focused on the minutiae of programming and the latest cool technologies that they just can’t see the bigger picture. Because they don’t understand the past they are condemned to repeat it (to paraphrase Santayana).

Much of the cycle is also driven by self-interest. The pundits make a very nice living selling books, consultancy and training. The journalists get something new to write about. The developers and team leads get to do ‘cool’ stuff and add some exciting new acronyms to their CVs. The vendors are happy to sell expensive new tools. Unfortunately the employers, shareholders and customers end up with late, over-budget and buggy software because the developers choose a cool new, bleeding-edge technology over something more mature and well understood. But it is too late by the time the problems become apparent.

Development environments are now vast ecosystems of languages, libraries and tools. Surely it is better to take the time to master one of these environments and understand its strengths and weaknesses, than to be continually chasing the latest fashion and never master anything. Better the devil you know than the devil you don’t. I am not against progress and I certainly don’t think we should try to use the same tool for every job. Many of the technologies I have listed above led to major steps forward, even if they didn’t live up to the initial hype. But software development should be a means to an end and we should never be so wrapped up in the technology that we lose sight of that. Professional developers should pay less attention to the latest fashions and focus more on solving problems for their customers. An experienced C programmer is almost certainly more productive than an inexperienced Ruby programmer. Wear your flares with pride.