No Silver Bullet refired

Software development is plagued with the Recipe syndrome: “Please tell me how to do my job”. From the utopia of some technology will increase productivity drastically to a prescriptive methodology to make every project successful, everyone is hoping for a silver bullet to kill their beasts [1].

Can the Software Development unpredictability be tamed by a well defined method? Will it come the time all software problems with be solved with a few clicks of the mouse? If you answer yes to any of these question, I have to congratulate you on your optimism. But I have bad news: your opinion will change with experience.

The methodology to save us all

Fighting people’s way is a very common mistake. People can be educated, but should not told what to do. Imposing processes will make people shut the brain off and follow blindly the directions. Any unforeseen situation on the process in use can lead to disaster [2].

Processes seem a very good way of eliminating human error: “if the protocol is followed, nothing wrong can ever happen.” This kind of thinking makes companies not protect themselves from human error, becoming more vulnerable to it. People will invariably fail. Safety mechanisms should be created to detect those errors before they cause any harm, even better, prevent them from happen. When you leave your car with the lights on, if the car starts beeping or turns them off for you, there is less changes you will get a flat battery. This is a good example of tolerance to human error.

Agile methodologies all agree on the unpredictability of Software Development and the key role thinking people have. Unfortunately, both are very often overlooked. We all know Extreme Programming practices: pair programming, code reviews, continuous integration… but not so much its values: “feedback” to adjust to change and correct what is not working; “courage” to admit failure and do something about it. Extreme Programming is not about following a recipe [3].

Every one, every team and every problem is different. Not too different, but enough to make certain techniques or practices fail in some cases. Forcing people to followed a prescriptive methodology is trying to fit a square peg in a round hole. After much complaints and pain, the whole methodology is discarded as unfit. Its time to fallback to the old ways [4].

The technology to save us all

We humans have a very funny way: every shiny new toy seems great, we get so excited to try it out. We get so mesmerized by its amazing features and potential, we overlook its disadvantages.

This common human “feature” is described by the Hype curve as the peak of inflated expectations. We will try to apply the shiny technologies on every problem, even if it’s not the best fit for it.

Gartner’s Hype Curve

Problems that seemed to be caused by inexperience, with time are proven to be cause by unsuitability for that situation. Most cases we overdid it and used it wrongly. Either case, everything is a mess now and the new technology is not that shiny anymore. It is time to move to the next hype.

4GL and the lot

The 4 what?! Beside being grumpy, I’m also old enough to remember 4GL and boring enough to know what it is. 4GL (4th Generation Languages) was an attempt to replace 3rd Generation Languages as C, C++, Java. The idea was to create powerful tools to solve every problem from a high level of abstraction. If C, C++ and Java are still around and you never heard about 4GL, means 4GL was not very successful.

Many other initiatives try to solve all problems and with only a few clicks. Take the example of RUP (Rational Unified Approach) idea:  model everything in UML and code will automatically be generated. Or ERP that intend to solve all business management problems with one single tool after a few tweaks.

Productivity can be very high on the beginning, until developers want to do something the tool was not design for. These tools become straight jackets to development. After huge investment is made, there is no turning back. Companies are locked into that vendor or tool.

Taking matter into own hands

Some get tired of waiting for the ultimate tool or technology, they decide to take matters into own hands: they will create such framework themselves! With enough investment and trust on their prodigious minds, work on the new Babel tower begins. The masterplan is breath-taking. It takes a genius to come up with such an elegant and well-conceived plan.

Years go by and a prototype is ready to be experimented with. It is not complete, but it is possible to see how easy life will become when everything is ready… except for a few details. It is just prototype anyway, we all know it needs improvements.

As the framework gets more use, more improvements and unforeseen use cases are found, until it takes a completely new direction from the initial idea. Some base decisions proved to be wrong and it’s too late to go back and correct them. Problems will have to be remediated with quick fixes.

Finally the master plan is deemed unfit and not worthy to continue investing on it. New developments are abandoned, even before it’s fully implemented. It is time to take the lessons learned, correct the mistakes and build what will be, this time, the ultimate masterplan.

Babel tower untold story

Everyone knows what went wrong with the Babel tower [5], but what the story leaves untold is its aftermath. What happen to what was already built? What is demolished? What it left to abandonment?

Unless companies go bankrupt, Software Babel towers are not thrown away. So much investment cannot go to waste and many solutions were built on top of it. They are refurbished and kept under use.

Software babel towers don’t exactly fail, they work fine, in most cases, most of the time. People will just have to bite the bullet and go around its problems. Babel towers will linger forever, making life hard to everyone who crosses path with it.


[1] “The Mythical Man-Month”, Chapter 17, Fred Brooks Jr., Addison-Wesley, 1995

[2] “Lean Software Development – An Agile Toolkit”, Chapter 5 – “Empower the Team”, Mary & Tom Poppendieck, Addison Wesley, 2003

[3] “eXtreme Programming Explained – Embrace Change”, Chapter 4 – “Values”, Kent Beck with Cynthia Andres, Addison Wesley, 2005

[4] “Agile Software Development”, Chapter 2 – “Individuals”, Alistair Cockburn, Addison Wesley, 2002

[5] “The Mythical Man-Month”, Chapter 7, Fred Brooks Jr., Addison-Wesley, 1995


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s