Code-and-Fix Development

The problem of not focusing enough on making rollers and preparing roadways is by far the most common problem in software. About 75 percent of the software project teams begin their projects by hurling themselves against the block and trying to move it with brute force.^[1] This approach is called "code-and-fix development" jumping straight into coding without planning or designing the software first. Sometimes teams do this because the team's software developers are anxious to begin coding. Sometimes they do it because managers or customers are eager to see tangible signs of progress. Code-and-fix development is universally ineffective on all but the tiniest projects.

The problem with the code-and-fix approach, as with the brute force approach to moving the stone block, is that quick movement off the starting line doesn't necessarily translate into quick progress toward the finish line. The team that uses a more advanced approach is putting a framework in place that will allow the project to spin up to a high level of productivity and finish efficiently. It is putting rollers under the block, clearing the roadway, and preparing to focus the energy of the project team. The code-and-fix project gets the block moving early, but it doesn't move the block far enough each day and the brute force approach isn't sustainable. It typically leads to the creation of hundreds or thousands of defects early in the project. Several studies have found that 40 to 80 percent of a typical software project's budget goes into fixing defects that were created earlier on the same project.^[2]

Figure 2-4 illustrates the way that productivity erodes over time on a code-and-fix project. Little or no effort is put into planning and process management at the beginning of the project. Some small amount of effort goes into thrashing (unproductive work), but most work goes into coding. As the project moves forward, fixing defects becomes an increasingly prominent feature of the project. By the end of the project, the project that uses code-and-fix development is typically spending most of its time fixing the defects that it created earlier.

Figure 2-4. Using a code-and-fix approach, the lucky projects finish while they are still eking out a small amount of productive work. The unlucky projects get stuck in a zone where 100 percent of their effort is consumed by thrashing, planning, and process management.

Source: Adapted from Software Project Survival Guide.^[3]

As Figure 2-4 suggests, the lucky code-and-fix projects are brought to completion while they are still eking out some small amount of coding progress. The unlucky projects get stuck on the far right side of the diagram where 100 percent of their available effort is consumed by planning, process management, and thrashing, and they are not making any coding progress. Without enough up-front planning, the code quickly becomes flaky and brittle. Some of these projects might be rescued by taking steps to push the team back to the left enough that they can eke out a release. The remaining projects are eventually cancelled.

This gloomy picture is no exaggeration. Several studies have reported that about 25 percent of all software projects are eventually cancelled.^[4] At the time the average project is cancelled, it's 100 percent over budget and is caught in an extended debug, test, and fix cycle (thrashing). The reason it's cancelled is the perception that its quality problems are insurmountable.^[5]

The irony of this dynamic is that these unsuccessful projects eventually do as much planning and process management as a successful project would. They have to implement defect tracking to manage all the bugs being reported. They begin estimating more carefully as the release date approaches. Toward the end of the project, the project team might re-estimate as often as every week or even every day. They spend time managing expectations of project stakeholders, convincing them that the project will eventually be released. They may begin tracking defects and imposing standards for debugging code before it's integrated with already-debugged code. But because they begin these practices late in the project, the benefits from these practices are leveraged over only a small part of the project.

The kinds of practices they implement are different from the kinds a more effective organization would implement in a project's early stages. And many of the practices they implement wouldn't have been needed if the project had been run well from the beginning.

As Figure 2-5 illustrates, the most sophisticated organizations those that produce the most reliable software for the least cost and with the shortest schedules spend a relatively small percentage of their budgets on the construction part of a project. The least sophisticated organizations spend practically their whole budgets on coding and fixing bugs in their code. Their total budgets are much higher because they don't lay any groundwork for working efficiently. (I'll return to this dynamic in more detail in Chapter 14.)

Figure 2-5. Advanced software development approaches require more work during the early stages of the project to eliminate an enormous amount of unnecessary work in the later stages of a project.^[6]

Code-and-fix development continues to be used because it is appealing in two ways. First, it allows the project team to show signs of progress immediately they can begin moving the stone block 10 meters per day the first day, while the more effective team is still out cutting down trees, preparing the roadway for a smooth trip, and showing no visible signs of progress on the real problem of moving the block. If managers and customers aren't very sophisticated about the dynamics of a successful project, a code-and-fix approach looks appealing. A second source of code-and-fix development's appeal is that it requires no training. In an industry in which the average level of software engineering training is low, it has been the most common method by default.

The code-and-fix approach is one form of software fool's gold. It seems attractive at first glance, but experienced software developers recognize it as having little value.