There Is Still No Silver Bullet In Programming

October 13, 2008

In 1986 Fred Brook wrote an article called No Silver Bullet: Essence and Accidents of Software Engineering (pdf). In it he speculated that there were no "silver bullets" on the horizon that could bring rapid advances to developing software similar to those in hardware. It's an interesting read even today.

So have we made that much progress in 22 years? Despite all the efforts of a lot of smart people I still don't see any silver bullets that guarantee massive gains in productivity, correctness, performance and maintainability. I managed to experience a lot of the changes in programming since I was a kid in the late 70's, yet despite all the advances I've tried, they barely keep up with the growth in demands being made by the "customers".

I always cringe when I hear or read someone who essentially says "if you don't do X your code will suck". It doesn't matter if X is a technology, a methodology, a language, a style or a tool, someone will always promote it as a perfect solution to all problems. Yet inevitably people switch to it and discover that it only works in limited circumstances or provides only marginal improvements at best, and may actually make development worse.

A silver bullet seems like it would slay the development beast and make programming so easy anyone can do it. In all my years I've heard that for everything from OO programming, 4GL tools, graphical programming, modeling tools, methodologies and management techniques. Some of these help but I've never seen anything that universally made programming easy. Programming is still hard and after all these years it seems to be getting harder instead of easier. Much of the reason of course is that much more is expected of the modern software project; the best hope for silver bullets today is to keep things from getting more difficult in the face of more complexity. Making things easy seems a hopeless wish.

Now for me I found PHP to be a silver bullet of sorts for my web development projects, compared to the Java I worked with for the past 10 years. I've also worked for a bit in Ruby-On-Rails and dabbled with Groovy, which both seems to improve on my Java experience yet none of these represents a common solution to all of programming's issues. Many of my irritants in Java projects had more to do with how the projects were run (into the ground mostly) than the language itself. With PHP I am doing things my own way which might be a large part of the improvement.

I've always thought the biggest silver bullets in any project are the qualities of the people working on the team (not just programmers, everyone involved is important). Smart, experienced people who work by consensus or at least in a trusting hierarchy, able to pick the right tools and technologies for the job, and given the right level of support by management, QA, product and everyone else who contributes to the end result. My 10 years of desktop application experience certainly taught me the value of have really good people who work well together. Working on Deltagraph for 5 years, we had basically 6 programmers, 2 QA and one product manager and turned out 5 major releases; the teams at other companies with similarly complex applications generally had much larger teams.

When I've worked in places or on teams which were mismatched, poorly lead, used tools incompatible with the team members, had overly complex methodologies, the result was uniformly bad. The dumbest project I ever worked on had 40 programmers who flew into Mexico (some from inside) every week for months to work on a project trying to customize a product (Websphere Commerce Server) not designed to be customized, led by people utterly unfamiliar with software development, and with a deadline every week. The use of WCS was supposed to be silver bullet to get an online store up quickly; yet the way it was used led to two years of expensive development before the entire company vanished and nothing ever came of it. Sometimes I think people buy silver bullets and then forget to buy a gun!

I am in complete with Mr. Brook's argument that he could see no silver bullets in the future. I won't repeat his discussion of why but I agree in principle that building software is still a complex solution to a complex problem, and that assuming that some magic elixir will be found to make simple solutions for those complex problems to appear is to ignore the many small improvements that do appear to help.

Everyone wants to find a silver bullet (not just in programming, but, for example important today, in things like banking) that make everything a breeze. It's human nature to believe in these things.

Will be still be saying the same thing 22 years from now? Will software development be so easy that anyone can do it? Will software be built by AI without human help? A realist would say no, but like the humans we are, we sure hope so.