Major problems with the waterfall

Java eases many C++ complexities, such as multiple inheritance and memory management. We have a good start, but the process that we use to build applica-tions is as important as the basic building blocks. In this review, we will briefly explore the impact of methodologies on antipatterns. Traditional application development, called the waterfall development methodology, can allow complex and large projects to be attacked but falls short as requirements get more dynamic (figure 2.7). In general, the waterfall methodology can also provide safe harbor for antipatterns:

■ The process resists change in general, especially new requirements. This resistance to change leads to fertile grounds for antipatterns, because we have fewer opportunities to refactor.

Figure 2.7 Jimmy Vick over the Sinks. This photograph shows a literal interpretation of major problems with a waterfall. In kayaking, cascades are tough because each dramatic drop can take a paddler further off of his line, eventually dooming the run. Programming schedules can be doomed when fixed in a sequence, slipping further with every major step in the cycle.

Major problems with the waterfall 45

■ The waterfall process can delay high-risk elements (such as integration) until late in the cycle, when it may be too late to recover. Antipatterns can thrive in such an environment. Quality control is back-loaded, and antipatterns found near the end of the cycle might never get fixed because of political pressures and expense.

■ The process forces complex one-time translations between major docu-ments, with no built-in accountability. For example, it is difficult to be sure that a program matches the original requirements. It is also difficult to determine where a functional requirement maps onto an end user’s requirement. This characteristic is called traceability. Process-related antipatterns can thrive because of the relative lack of accountability.

2.5.1 Iterative methodologies

Iterative methodologies improve this process by providing short cycles with increased accountability throughout each cycle. We can adapt to change and address key risk elements early. Iterative methodologies help to thwart antipat-terns by doing the following:

■ Iterative methodologies provide more opportunities to refactor, usually after each cycle. We then have an antidote for antipatterns that are discovered.

■ Deliverables, called artifacts, trace end-user requirements from the beginning throughout the entire process after each iteration. This trace-ability improves accounttrace-ability and quality. In such an environment, process antipatterns are more easily exposed and addressed.

■ One of the cornerstones of a good development process is to build in increasing value as the cycle matures. With an iterative process, it is much easier to do so. Managers can define functional releases from a very early stage, with extra functionality delivered throughout the process that builds in additional use cases with each successive iteration. Reducing scheduling pressures by accurate sizing can also help code quality.

2.5.2 Mini-antipatterns: Incomplete Process Transitions

Many projects never see the full benefits of object-oriented technologies and related methodologies. They fail to make an effective transition from the tradi-tional waterfall process. Here are some common mistakes:

■ Poorly defined iterations. It is easy to look at an iterative methodology and incorrectly infer that the process is unstructured. Many project managers do not attempt to set a comfortable rhythm of release cycles.

46 ^{CHAPTER 2}

The bitter landscape

In these cases, it is tough for a team to develop a set of repeatable prac-tices that work for the team.

■ Poorly defined stopping points. I visited customers in the mid-1990s that are probably still iterating on a single release. It is important to specify a set of metrics that define the completion of a project or a phase. Usually, the iteration units include a finite set of use cases, with some flexibility to remove or insert additional cases as time permits. The flexibility must be constrained by the business environment, though. Sometimes, differ-ent phases of the process are overemphasized. For example, too many iterations over the requirements and design without a clearly defined exit strategy led to the term analysis paralysis.

■ Overmanagement of the artifact set. Object-oriented tools and processes can produce a staggering amount of paper if left unchecked. When working at a startup, we were trying to get our cycle time down to six weeks. As we were building the Client Services organization, two man-agers with mostly procedural process experience produced a process that would require a staggering 30 artifacts! Each artifact must contribute to the delivery of a quality product to the customer. Additional artifacts should be added only to the extent that they patch holes in the existing development process and lead to better efficiency or quality.

■ Poor teams or inadequate education. Most projects that succeed do so because of good teams with strong knowledge. Investments in the qual-ity of the team, especially when teams are new to object technologies, cannot be overemphasized. In addition, it never ceases to amaze me that many extremely strong teams have completely inadequate hiring processes. Investments in consulting to shore up the interview process or good recruiting companies usually provide outstanding returns.

Effective education and leadership can go a long way toward steering clear of many of these problems. In fact, many organizations seed small projects with high-powered consultants who ser ve as mentors to jump-start a project.

Hands-on training under effective leadership can be an extremely strong edu-cational method.

2.5.3 Programming horizons: Extreme programming

Some recent refinements to iterative development have shown promise under the label of extreme programming. Kent Beck introduced this methodology in a book called eXtreme Programming eXplained. This refined process uses a collection of simple rules and practices to form a disciplined and

team-Major problems with the waterfall 47

oriented approach to software development. The process is described in detail at http://www.extremeprogramming.org. Most of the rules are bor-rowed from other processes. My intuition is that the methodology will prove to be highly effective at combating antipatterns. Here are some of the key rules of extreme programming:

■ Choose simple solutions. Extreme programming advocates the simplest solution that will work, because of the ease of development and mainte-nance. Simple solutions are much less likely to create antipatterns, or to hide the ones that already exist.

■ Ensure that the customers are on site. Throughout the programming cycle, end users should be available to provide guidance, insight, and opinions.

■ Write user stories. These serve the same purpose as the use case. They are a few sentences of text, written by the users.

■ Divide larger projects into measured, planned, small releases. Smaller cycles result in user feedback, diminished risk, and adaptability to change. Small cycles also allow antipatterns to be found and refactored sooner, through more frequent code examination at every cycle.

■ Refactor early and often. Refactoring involves redesigning solutions in order to improve readability or design and remove redundancy or unused code. Extreme programming operates under the philosophy that refactoring is a wise investment. Refactoring helps eliminate antipatterns.

■ Program in pairs. This practice seems wasteful but has tremendous power. Pair programming improves quality and reduces tunnel vision.

Antipatterns are more likely to be spotted with an extra set of eyes.

■ Code test cases before the rest of the system. This practice helps to flesh out the requirements and ensures that new classes will meet specifications.

■ Do not use overtime. This is probably one of the most useful—and least used—ideas in extreme programming. Overtime increases available hours and reduces clear thinking, with predictable results.

Extreme programming also introduces other practices that are not outlined here. The methodology is garnering strong momentum among developers. I used many extreme programming practices at allmystuff and endorse them heartily. Such excitement and promise from a new methodology that actually simplifies the development process is promising, and many of the practices build a culture of teamwork and merciless refactoring that can thwart antipat-terns before they start.

48 ^{CHAPTER 2}

The bitter landscape