Fred Brooks in his book, The Mythical Man Month, posited that there is no “silver bullet” of development. What he meant by this is that there is no magical process or tool to create software. Is this still true today? By all means, yes. Just like when this book was written, there is no silver bullet today. How many silver bullets have you heard of in the last 10 years? The answer is: plenty.

CASE (Computer Aided Software Engineering) Tools

The first silver bullet I remember encountering was a set of tools called CASE tools. CASE tools provided developers with tools that helped create data flow diagrams, state transition diagrams, procedure charts and numerous diagrams and charts. These tools supported numerous methodologies created over the years by true gurus like: Ed Yourdon, Tom Demarco, Larry Constantine and others. The theory was that applying CASE tools to the software development process would result in better software, simply by using these tools. Did the tools help in developing better software or was it the methodologies that these tools facilitated?

Java

Never has there been a more over-hyped software tool than Java. The myth of Java was that it would facilitate developing cross platform applications. The marketing hype said, “write once, run anywhere.” The marketing hype was so prevalent that Netscape changed the name of ActiveScript to JavaScript in their Navigator browser. While their language was “Java-like,” it really had nothing to do with Java at all.

Was Java a useful development language? By all means, yes. Did it solve all software development problems? Some. Java is a tool that powers a large number of server-based Web applications. The most prevalent area where I have seen it is in the banking sector. I frequently see the .JSP extension on Web pages. These are Java Server Pages that run on Web servers behind the scenes. Another area that uses Java extensively is the online gambling industry, but that is another story.

The Unified Process (UML)

A few years ago, a new software development methodology emerged. This was the Unified Process and was created by Grady Booch, Ivar Jacobson and James Rumbaugh. This process was essentially the software development process for the object-oriented world, and another silver bullet. It was supposed to provide developers with the way of modeling and developing software for the modern world.

Has this methodology delivered software developers to the “promised land”? I don't think so. From my experience, I have seen developers use these tools to over-engineer software development projects. So is the Unified Process valuable? Yes, as it does provide a framework and common language for describing complex projects.

Extreme Programming

The latest methodology to emerge is that of Extreme Programming. Extreme Programming has a number of interesting aspects to the development process that make absolute sense. Pairing programmers on writing code is a good idea and writing testing plans before writing code is a good idea. Is Extreme Programming for everyone? No, no methodology is for everyone. While this methodology has its merits, it shows weakness when dealing with smaller development projects and IS shops. Is it a “silver bullet”? I think the answer is, yet again, no.

While all of these technologies have their individual merits, they are not the “silver bullet” developers seem to look for. So is there a silver bullet? Yes, I believe there is.

Common Sense is the Silver Bullet

While growing up, I heard my father constant espouse the idea that common sense was the way to guide you in your actions. Actually, he said it in terms like, “Boy don't you have any common sense?” (Most boys don't come equipped with much). Eventually, what he said sank in and, many years later, I realized he was right. When I develop software, it is common sense that guides me.

To understand this you need to take a close look at what you do for a living. Do you consider yourself to be a Visual Basic programmer, a SQL Server or Oracle DBA, a Visual FoxPro programmer or a Java Developer? Or, do you consider yourself to be a software developer? I have actually taken it to another level. I consider myself to be a problem solver.

What we really do in our everyday work is to solve problems for our constituents. It is our job to learn what problems our constituents have and to develop software to solve these problems. The tools and methodologies mentioned above help us in solving problems, but they are not the solution. They are only tools used to get to a solution.

So, you may ask, “Rod, do you use any of these tools?” The answer is, yes I do. I use bits and pieces from each, selecting the correct tool for the job. However, there is one set tools that I always use: a Mead composition book, a pen and a good dose of common sense.

I would love to hear your comments.

Thanks,

Rodman