be buggy, they create one more unknown in a project. When a defect is found, is the product or the tool at fault?
Tools range from simple and indispensable text editors and compilers to more elaborate environments for analysis and design. Very few outrageous claims are made from the developers of editors and compilers-it's the design tool vendors that corner that market. What's more valuable to a project anyhow, a nicely drawn E-R diagram or a programmer who's expert in the target implementation language? Would you buy $100K worth of tools or hire a person who intimately understands the problem domain in which you are involved? Tools are great when used properly, but they can only offer you steep learning curves and limited functionality. Plus, they bring along a whole new set of bugs to worry about: their own.
You see, if tools really were a silver bullet, they wouldn't be buggy, would they? Strike two.
The latest attempt at getting the software quality problem under control has been made by the process improvement people. Obviously, controlling and improving the software development process is in everyone's best interest. However, since software development is a technical problem and process improvement is a management problem, it simply cannot have a profound effect on quality. Good organizations can produce bad software. Bad organizations can produce good software.
Furthermore, process improvement initiatives are rarely met with enthusiasm from rank-and-file technical people. ISO certification is a pain. SEI assessment is demeaning. Both take away creativity and add management overhead. Heck, part of the joy of working in this field is not being micro-managed. Why would any developer in his or her right mind actually think this is a good idea?
Well, it is a good idea, but it won't help appreciably with the quality problem. I was once a part of a partnership in which a consulting company that specialized in formal methods was training an SEI level three-on their way to level five-organization. An example code fragment was used extensively throughout the training. Neither the formal methods advocates who wrote the buggy code, nor the mature process organization that studied the code, noticed that it possessed a fatal flaw. Not even during the course of proving the code fragment correct was the bug ever discovered. Why? Because the formal methods people were concerned about math and the process people were concerned about documentation. No one was looking at the code! Fortunately, the test organization was paying attention and the bug was caught.
Management solutions cannot solve technical problems. Strike three.
The Fourth Proposal
What we need is for someone to come up with silver bullet number four. Except this one shouldn't be silver. In fact, I think it's important that proposal number four should be bland-colored, say brown, so that no one really notices it. It shouldn't be something so revolutionary (as a gold or platinum bullet might be) that it makes no sense and people avoid it. It should be so ordinary that developers can integrate it seamlessly into their normal pattern of design. It should be so straightforward that developers remark "this is simple, what's the big deal?" Not only should it be these things, it must be in order for it to be used and have some positive industry impact. Otherwise, it's just more ivory-tower nonsense that real practitioners don't appreciate.
It turns out that parts of such technology exist, are readily understandable by capable developers, and will not fundamentally change the manner in which software development occurs in an organization. If you are a great developer now, then