Works on Your Code!
First, an explanation: "No Silver Bullet" refers to a paper that Dr. Fred Brooks, program manager of OS/360 and author of the *very* good book The Mythical Man-Month, wrote several years ago, claiming that there was never going to be a "silver bullet" to cure programming problems. He got the name from the general belief that the American Cancer Society's search for a "magic silver bullet" to cure all forms of cancer was a failure and always would be.
In his paper, Dr. Brooks argues that, similar to the fruitless search for a magic silver bullet cure to cancer, we programmers should stop looking for a magic silver bullet to cure the woes of software development and maintenance.
It may seem surprising that a software vendor touting a product with claims of significantly faster development would agree with Dr. Brooks' "No Silver Bullet" premise, but let me explain: while I agree with Dr. Brooks that there will never be a total cure for all software woes, I disagree as to the reason. Dr. Brooks claims that the problem is too difficult and diverse, and therefore can never be solved, so we should stop looking.
Lots of Silver Bullets
I feel that there have already been a number of "Silver Bullets," and that they largely have solved the programming problems that they were designed for. For examples, I offer:
So How Come We Still Have Such a Backlog?
Or, "How come we're still in such a mess?" After all, the programming gurus are still proclaiming a "software crisis," which sounds remarkably like the original software crisis of 1968. How can we have the same problems almost 30 years later if there have been multiple software "Silver Bullets"?
The answer is simple. We don't have the same problems at all-- they just seem the same. In 1968, the year the first "software crisis" was declared, a typical program was trying to do simple, text-oriented reports, or database operations. A large program in 1968 had 10,000 to 50,000 lines. The programming technology of the day couldn't reliably support anything larger. Those "large" programs of 1968 wouldn't even justify a programmer to work on, today -- they are just handled by end-users making requests to a "Silver Bullet" program.
In 1997, a program doesn't become "serious" until it reaches 100,000 to 500,000 lines. "Large" programs now can have 1,000,000 to 5,000,000. And there exist some commercial programs, such as Microsoft Word or Microsoft Excel, which are moving into the 10,000,000+ range!
We have indeed had software silver Bbullets -- we've just used them to raise our sights (and our sites!). We commonly do today what would have been a miracle in 1968. Each silver bullet has been successful -- not solving the software crisis, but rather increasing the scope of the problems we can help solve.
Backlogs are Forever!
The reason that backlogs haven't shrunk at all in the last 30 years is that as soon as we find and deploy one silver bullet, our users raise their demands and expectations. We keep using our silver bullets to increase the complexity and scope of what we are doing. That's what makes software soft, and what makes it so much fun to work on.
The length of backlog is more a measure of the psychological make-up of the user community ("How much can I ask for and have a chance of getting before I will be promoted out of this job?") If we could invent a program that would do everything but read the user's mind, the first enhancement request (or competitors' release) would be to add mind-reading. In other words, backlogs are forever. Get used to it.
In the meantime, look for, find, and enjoy the Silver Bullets (and I don't mean beer) that are out there!
I hope you will consider our candidate for the "Software Silver Bullet," InstantC. Thanks for listening!