Many software teams adopt the top-down approach to software development. Others prefer the bottom-up approach. They’re both high-risk techniques you should avoid. Here’s why.
The Top-Down Approach
Traditional waterfall teams like this approach. It starts with analysis and works its way down to implementation.
The approach begins with high-level market or process analysis (depending upon the problem being solved). Goals and objectives are assessed. Business requirements are gathered. System architectures are defined. The team gradually works through these aspects of system design until they feel they are ready to begin implementation.
Seems reasonable, doesn’t it? So why is the risk high?
- The team will need to make assumptions about what can and cannot be implemented within time and budget constraints — especially if any of the technologies involved are new to the team.
- If the team tries to minimize technology risk by selecting a conservative implementation, the competitiveness of the resulting product may be compromised. The new product won’t break new ground.
- Time and budget estimates to complete the project are likely to incomplete or overly optimistic. There are simply too many implementation details that remain unknown.
The Bottom-Up Approach
Immature agile teams like this approach. It starts by writing some code, seeing what happens and writing some more. (This often occurs when the team lacks a product owner.)
The approach isn’t as undisciplined as it may appear. Ultimately, the best measure of progress is working software. So why not start writing code early in the project? Write, test, review, optimize, repeat. Before long, the team has a complete software system.
So what’s so high risk about this approach?
- The team begins writing code before they have a thorough understanding of the problem space. They know enough to begin the implementation but face many unknowns as they progress.
- Lacking an in-depth understanding of the problem, the team may make design decisions that prove to be less than ideal. They will be forced to either take extra time to correct those decisions or live with them and face the consequences.
- Having all of the known information imbedded in the code, makes it difficult for non-technical people to understand the system or visualize the solution.
The Hybrid Approach
Extreme approaches to software development introduce extreme risks. If your team is comfortable with the risks, pick an approach and go. As for me, I prefer to mitigate risks.
The idea behind the hybrid approach is to start top-down and before making too many assumptions, begin the implementation. In other words, keep analyzing and designing as long as the team is comfortable with and sure about the decisions.
At some point, the team will begin to lose confidence in its decision-making. The number of unknowns may grow too large or the complexity of the solution may become overwhelming. Either way, it’s time to stop analyzing and start implementing.
The initial implementation should focus on the unknowns and the complexities. Once more knowledge is gained, the analysis may resume in parallel with the implementation.
Are there still risks? Of course, there are. Software development is a risky business. Don’t make it worse by taking extreme measures.
photo credit: Drift Words via photopin cc