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.
mark 10/13/2008 11:05
Take haskell. A very difficult language.
I do not think it is a good language FOR EVERYONE.
But I would love to have a programming WAY FOR EVERYONE.
I guess it would have to be visually somehow, at least as an option for those that dont want to type in huge amounts of text.
andrew 10/13/2008 14:01
there isn't a silver bullet but there have certainly been advances in terms of best practices e.g.
not silver bullets, but pretty fine ammo all the same
Ray 10/13/2008 14:34
I think people over look the simplicity of solving a problem. Developers can get over worked by code standards or frameworks that simply providing a solution gets a lower priority. I think that is were a iterative development is beneficial. It allows you to solve a problem in version 1.0 and then refactor code for easy reuse in version 1.0.1. This works for most situations. I think the goal for any project is to provide solutions while ending up with software assets (resuable components). Thoughts?
BTW: I like the resizeable comment's box. NICE!!!! I also dig the cancel and remember your text feature......
Thijs Blaauw 10/13/2008 14:46
One of the main points of Mr. Brooks' essay was that coding was but a small part of building a system. More important was understanding the problem, the business requirements. I do believe that modern languages, modern tools and modern development methods are more efficient than those that were available at the time that Mr. Brooks wrote 'No silver bullet'. That means there is even less room for a 'silver bullet' improvement on the technical side now than there was then.
Alex Chacha 10/13/2008 17:09
When you start looking for a silver bullet is when you have already gone down the wrong path. People looking for silver bullets often have software that is based on poor initial decisions (like building a castle on mud). There are many ways to send a project into a tailspin: novices designing software, design by committee (often results in lowest common denominator design), unwillingness to constrain oneself to a platform (resulting in low feature code constrained by low common functionality across various platforms), and so on. A language is rarely a problem, the process is. You mentioned that the best part was doing things your way, which is a start. Discipline and proper management are essential also. It is too often that people managing developers are just business people who do not (and often cannot) understand the basis of software development (repeating the mistakes of Mythical Man-Month and Death March, or treating resources interchangeably). The more non-technical people you have managing software the more of a chance there will be a mess at coding level and more likely they will be looking for this silver bullet only to realize it doesn't exist but they will spend lots of money along the way on consultants, fancy development methodologies and questionable RAD technologies. The sad part is, most will learn nothing from this and will repeat it in the next project because they did not understand that what go them there is how the project is managed and designed. Alas...
MFR 10/13/2008 17:45
AI doing the programming would be super cool. But you have to be careful so they won't take over the world. ;)
Michael Chermside 10/14/2008 05:07
There is one misconception I would like to correct: your definition of "silver bullet" as something that "would slay the development beast and make programming so easy anyone can do it" is a bit different from Brooks' definition.
He defined it as any advance that would give an order of magnitude improvement (factor of 10) within a decade in productivity, reliability, or simplicity.
Brooks' definition is, I believe, far more interesting and engaging because I don't know of anyone serious who claims that their tool, practice or methodology will "slay the development beast", but I DO read serious claims promising 10-fold improvements. Agile development is one -- while I think use of Scrum is a great idea, I don't really believe it will give a 10-fold increase in productivity. Concurrent programming is another; I am sure the machines will run 10x faster, but I doubt that the programs will.
Alex 10/14/2008 12:04
"I am in complete [agreement] with"? You likely missed a word there.
Razor 10/14/2008 14:33
I agree that there is no silver bullet, butI'm sure of few things.
On the other side I think that one of the most important thing that far to often is underrate is the qulity of documentation. An here I must admit Microsoft is rather weak, Sun/Java is quite good, IBM is simply the best: browse IBM documentation and even in PDF you find more easely what you need than in html from others.
I don't know how much Aspect orientation and/or annotations will help. But for sure I would like to be able to use more of literate programming.
silvery and bulletproof 10/14/2008 16:02
of course there's a silver bullet
these days' its called 'Agile'
or 'SOA'
depending on which vendors the suits play golf with
John Keklak 04/23/2009 11:34
As Michael Chermside clarifies, Brooks' silver bullet would be some "single development, in either technology or in management technique, that by itself promises even one order-of-magnitude improvement in productivity, in reliability, in simplicity."
Reliability has gotten remarkably good, but that may be dependent on what software you use and how you use it.
Simplicity has been lost for the most part. CPU speed, vast amounts of RAM and hard drive storage, network speed, debuggers and other development tools have made it possible to create gargantuan monstrosities.
Twenty-two years ago it would not have been possible to build, run and debug these things, so we had to make less complex programs. Today, a edit, compile, debug cycle takes pretty much the same amount of time. It's just that the volume of code involved is so much larger.
Most programmers will admit they don't really understand the code they are working on as well as they should. Part of the problem is (and I'm generalizing again) that people spend the bare minimum thinking about good ways to do things, and instead, do the most expedient thing, especially when fixing bugs in unfamiliar code. This leads to a huge amount of complexity.
As for productivity, based on my experience, there's been no discernible change. It seems to take about the same amount of time to fix a bug or implement the typical feature that it did twenty-two years ago. From a product release standpoint (and once again based on my experience) there is no difference in the length of a release cycle.
With respect to productivity, Brooks hits the nail on the head with his statement: "I believe the hard part of building software to be the specification, design, and testing of this conceptual construct, not the labor of representing it and testing the fidelity of the representation." In other words, thinking things through and resolving conceptual errors takes just as long now as it did back when programming first started.
In short, I don't think anyone is going to argue that increasing software reliability should be the top priority. I also don't think many people will argue that simplifying code should also be the top priority (although the level of complexity directly makes life quite miserable for most programmers).
However, if some methodology is able to reduce release cycle time from twelve months to one or even two or even three, it seems there would be great consensus for making the use of this methodology a top priority (imagine how marketing would salivate over such prospects!). Sadly, the likelihood of the existence of such a practice is somewhat low, since the practice has little to do with how programming is done. Instead it has to do with how quickly people conceptualize products, and work out the conceptual problems, which in some cases involve politics.
Anyone got a developer studio or methodology that deals with these issues?