Sometimes the quickest path is not a straight line. This definitely applies to the software development life cycle, which is an iterative, not linear, process. It may be simpler to code, test, and then debug in isolated and linear phases. But this approach is definitely harmful to your application. This is one circumstance where you should enjoy traveling in circles. My best advice—learn to multitask.
First, the linear approach will undoubtedly extend the development cycle. Without some degree of parallelism, the project is elongated. In the competitive and fluid business climate of the Web, unnecessarily extending the business cycle can be fatal. In addition, every day spent developing the project is an additional day of lost revenue. Even if you are not in management, marketing, or sales, lost revenue is important—especially for developers who hope to keep their jobs into the future.
Debugging while coding is essential. The goal is not simply to complete features like items on a checklist. You will complete the application but not be truly done. Actually, you won’t even be close. It may take you an equal amount of time to resolve all the unaddressed problems in the code. Worse yet is that debugging at the end of a project is the worst possible time. Here are some reasons:
Problems that could have been resolved earlier have had an opportunity to replicate in your code. Fixing bugs is about education and communication. Fix the bug early, learn from the problem, and communicate this to others on the team. This prevents others from repeating the same mistake in the application.
Bugs are easier to resolve when you have recently worked in the relevant code. Later, when the code is cold, finding the proper resolution will inevitably take more time.
Some bugs could require a redesign of some portion or the entire application. This is best discovered earlier and not later. Delaying that decision can be costly. You are in essence building your application on quicksand. The more code you write, the more code you will have to eventually rewrite.
"Bugs beget more bugs." Developers should start each morning by repeating this mantra during 15 minutes of meditation. Waiting to debug at the end of the project means you will have no idea how many problems truly exist in the application. Why? You will introduce new bugs while fixing the known bugs. In addition, correcting existing bugs will likely uncover bugs that were already there but unseen.
Ongoing bug fixes are an important barometer of the quality of the application. It could highlight systematic and technical problems beyond a simple fix. By delaying bug fixes, you could obfuscate the fact that you are creating a weak application. Reviewing bug fixes early on could uncover the presence of an inexperienced developer. Don’t you want to know that before that developer contributes reams of code to the application?
Finally, you are setting false expectations with management and customers. Reporting on the completion rate of the features is misleading. If you are fixing bugs at the end, for the reasons already described in this chapter, you will have no clue when the project will actually be finished. You are more likely to be able to predict the next five winners of the Super Bowl than the correct end date of your project. This will set up a battle among you, the management, and the customers. The team will use shortcuts to get the project released, and the quality of the application will suffer.
