We can debate the pros and cons of one development process over another until we're blue in the face, but the simple fact is that we will never declare a true winner. There simply is no silver bullet development process that will help every development team deliver every product on time and on budget. This article provides a brief overview of three development processes and when they are most appropriate.
Trendy development processes come and go, but the debate over which software development process is “best” never seems to end. At almost any industry conference today, you’re sure to hear someone condemning the waterfall process, proclaiming that design is dead, or wondering if process is even relevant considering today’s compressed project timelines. In my opinion, you can gain a lot more from retiring the “Which development process (if any) is best?” question forever, and replacing it with a slightly different one: “Which development process is best for my project?”
We can debate the pros and cons of one development process over another until we’re blue in the face, but the simple fact is that we will never declare a true winner. Why? Because different processes have different strengths and weaknesses. There is no silver bullet development process that will help every development team deliver every product on time and on budget. Likewise, there is no “good for nothing” development process. Each development process is viable and useful, but each one works better in some situations than it does in others.
Moreover, most companies (in my estimate, about eighty percent of them) do not really have any development process in place—even if they think they do. A development process that’s on paper is not sufficient. For a development process to be useful, it must be implemented and followed on a daily basis. But before you start worrying about which development process is best, you should implement some kind of defined, repeatable process in your organization. One thing is for certain: any development process is better than no development process.
What Process Works Where?
The Waterfall Process
If you’re working on a somewhat traditional project (for instance, an accounting system) where the features are defined a priori and it’s possible to freeze the specification, the waterfall process is your best bet. The waterfall development process starts with one long design phase that defines the entire project and all of the product’s features; this phase typically includes requirements analysis. Once the design is set in stone, the implementation phase begins. After all features described in the design phase are implemented, they are integrated into a working product. Finally, the product is tested, and then it is shipped to customers. The flow of these phases is represented in Figure 1.
Figure 1: The waterfall process moves through each phase of development until final release
When you adopt the waterfall process, you define the project's scope up front and try not to change it. As a result, you have the information required to set a realistic schedule and budget, and you're typically free from the surprises that often throw projects off track. That's why the waterfall process is typically the most efficient and economic choice if you are building a well-defined system. However, it's not feasible in all situations. Often, it's impossible to define a project's scope up front-especially if you're working on a truly ground-breaking project. Many of the teams working on ground-breaking projects start off with no concrete idea of what the final product will look like, or change directions midstream. If these teams refrained from revising their projects' scope because they believed revisions were not allowed in their development process, they would most likely end up with less impressive products…or none at all. In this case, the waterfall model that typically works so well for more stable products would end up being an obstacle to the project's success.
The Spiral and Incremental Processes
If you're working on a project whose nature and scope are vague
About the author
The opinions and positions expressed within these guest posts are those of the author alone and do not represent those of the TechWell Community Sites. Guest authors represent that they have the right to distribute this content and that such content is not violating the legal rights of others. If you would like to contribute content to a TechWell Community Site, email editors@techwell.com.
