Developer.com content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.
Frederick Brooks, in his classic text on software development The Mythical Man-Month, has described software development as similar to a prehistoric tar pit, where great and powerful beasts thrashed violently but, ultimately, were unable to free themselves from death. He asserts, with obvious truth, that programming teams become mired in their own tar. The problems of software quality, limited resources, tight deadlines, and user acceptance often drag a project lower and lower until it too meets an unpleasant demise.
In an effort to tame the tar pit, various researchers in the software engineering field have proposed methods of software development that promise to bring sanity to the programming process. This is good, since software engineering certainly is a field that needs all the help it can get. The problem is too many researchers have proposed too many overlapping and competing methods. The putative solutions have formed their own mess. In an article and a frightening graphic presentation, Sarah Sheard has described the situation as “the frameworks quagmire”.
Ms. Sheard’s characterization is apt and she presents much valuable information. Unfortunately, reading her article is likely to leave one more confused than before, because there are several important points that her work does not address clearly. Chief among these omissions are:
- Why do we have this mess? Why have so many people and organizations written so many software development models?
- What should a real-life software development manager do? What standards are worth following when a manager is tackling an important, high-risk software project?
- What about the popular work of non-institutional writers such as Kent Beck (associated with extreme programming and Steve McConnell (author of Code Complete and Rapid Development)?
There are two reasons we have so many competing software development models, one obvious and one not so obvious. The first reason is the familiar “not invented here” syndrome. It is easy to think that we can create a new software development method that has all the strengths of the known techniques, with none of their weaknesses. (I have made this mistake myself.) In reality, any new framework we invent may improve current methods in some areas, but will fail in others.
The second reason we have so many software engineering methods vying for acceptance is some of the competition between them is an illusion. The methods operate at different levels of abstraction and, therefore, are complementary rather than competing. An argument about whether the Capability Maturity Model (CMM) is better than Steve McConnell’s books is like trying to decide whether a Chevrolet is better than a V8. Cars and motors are not the same thing and are not comparable. Some of the popular software development methods are actually meta-methods; they list the goals a development method should achieve, without specifying how to get there. CMM is just such a meta-method. Other models offer detailed prescriptions for how to run a project day-to-day. Steve McConnell’s books offer this level of detail, and can be used as an implementation plan within a meta-method.
So what is a poor software manager to do about all of this? Certainly, reading Ms. Sheard’s scary chart is no help, even though it is an accurate depiction of the frameworks quagmire. Sending your programmers to courses about dozens of competing (or overlapping) development models is not realistic. Instead, I offer the following advice for pulling your feet out of the programming tar.
Advice #1: Unless you are a full-time researcher in the software engineering field, don’t invent another software development method! I’m sure you are a very smart person, and you might even think of a few things other people have overlooked. But the world does not need another programming model right now. Rather than trying to create a better wheel, be a little boring and use methods that already exist. None of them are perfect and someday we’ll have better methods, but there is probably one that fits your needs reasonably well.
Advice #2: Learn the basic ideas from these key programming frameworks: CMM, Extreme Programming (and the closely related Agile Software Development), and the methods of Steve McConnell. These three methods cover a heavyweight, complex management model for large software organizations (CMM); an alternative method that specifically does away with the bureaucracy of CMM; and an individual writer’s collection of his personal tips and techniques (McConnell). If you learn a reasonable amount about these three frameworks, you will know a large percentage of the important current work in software engineering.
Advice #3: Don’t be a slave to any method. Take everything the experts have written and consider it a set of suggestions that may help you. Think creatively about how the popular methods apply to your organization and your problems. Use what works and modify what does not. This advice sounds contradictory to #1, but it is not. Every serious researcher in software engineering knows their method does not make sense in all situations. The method frequently criticized for being the most rigid (CMM) states this caveat clearly in its opening pages. So don’t place more faith in any framework than its own authors do.
By following this advice, you can pull some of your paws out of the software development tar. With a little luck, your project might even flourish in competition with other beasts trying to beat it to the water hole.
Charles Connell is president of CHC-3 Consulting, teaches software engineering to corporate and university audiences, and writes frequently on computer topics.
