3.1 Understanding the Problem

Communication is a huge part of programming. Writing better Java won't do you any good if you're building the wrong thing: you must understand before you can code. As you advance in your programming career, you'll find that more and more of your job demands effective communication. It doesn't really matter where your requirements come from—your team lead, an analyst, or the customer. In each case, your first job is to accurately gather each requirement and focus your customer on what you can reasonably achieve with your resources at hand. Don't plow your customer under with enormous requirements and arcane design documents. If the customers can't understand your documents, they can't focus on the real issues. Like your code, keep your requirements simple and clear.

If you don't like communication, I've got news for you: things are going to get worse before they get better. In a global economy, you've got to be efficient. Increasingly, that means developers must handle more and more of the software development process. Out of college, I worked for the largest software company in the world. We had more testers than coders on a project (often, by a factor of 3 to 1), and teams of 10 planners supporting 40 developers. The overall effort was 200 developers strong. Now, that project might use 10 developers and half the original timeframe to develop the same piece of software. Since the development of better automation and unit testing, each modern developer must shoulder more of the testing load. Coders also do more design work and planning than ever before. However, experience shows that many of those developers are not equipped to handle many of the increased planning and analysis roles that they face.

3.1.1 Gathering Requirements

This book would not do its readers justice if we didn't talk about dealing with change from a process perspective. If you're one of those shops that tries to do more with less, you need to do two things in the planning process: first, weed out software requirements that don't contribute much to the final project, and second, weed out unnecessary work that supplements traditional development but does not contribute much to the overall content or quality of your code.

Many programmers believe that they need to build object-oriented design documents like class diagrams or object interaction diagrams in order to support development. The danger with this approach is that you can spend too much time maintaining your design documentation, and not enough time building working code. The best design resources are a lightweight requirements list, working code, and an on-site customer. A requirements document often consists of little more than single line items, each taking less than half a day to several days to complete. Often, you don't need formal project management software. I've managed requirements with expensive project management tools, word processor documents, and spreadsheets. Low tech usually works better than high tech.

3.1.2 Controlling Scope Creep

Once you've got requirements together, you'll want to keep a manageable scope. I often spend a good deal of my time improving communication and understanding at client sites. By far, the biggest problems I encounter come from controlling the scope and expectations of the project. Often, the power comes from a pocketbook, so it's tempting for those in charge to try to add whatever features they want, whenever they want them. There's a necessary tension between productivity and change. Many teams succeed because they adapt to rapidly changing requirements, but just as many projects falter because teams fail to adequately control scope. This is the central problem in software development. The only way to effectively develop software is to succeed at solving this problem.

3.1.2.1 Managing good change

Iterative development is effective partially because it allows you to adapt. But regardless of the process that you use, your customers must understand the overall cost of change. Whenever someone requests significant changes, you can't threaten to beat them with a plastic whiffleball bat. You've got to be receptive but firm. Your first response should be something like, "We'll try to work it in. Let me tell you what it will cost." This type of answer immediately gives your customer positive feedback, and also lets them know that change affects the overall cost of the project. It doesn't matter who the customer is. Whether your project is internal or external, some facts never vary: development takes money, time, and manpower. You can only do so much with a given pool of resources.

Figure 3-1 illustrates the three ways you can react to expanded requirements:

Figure 3-1. Reacting to expanded requirements

You can also combine two or more of these options. The first method is by far the best.

Notice that increasing hours is not a viable option. Heavy overtime means that the project managers are not doing their job. (Increasingly, the developer is the project manager!) Heavy overtime usually leads to defections, mistakes, and sloppiness that cost more in the long run. Nor should you increase your manpower in other ways. Unless you're grossly understaffed, increasing the size of an optimal team is going to sacrifice efficiency, and may even delay the project further. Scheduling conflicts also cause problems. If you frequently slip your schedules, you're delaying the value to your customers, and that's rarely a good idea.

By far, the preferred way to pay for a change in a release is to push other functions out of the release. If you get into the habit of negotiating a healthy give-and-take with your customers, they'll get better at understanding of what's most important to them, and you'll get accustomed to delivering on your commitments.

3.1.2.2 Curtailing disruptive change

The ability to react to your customers is important, but not all change is good. Disruptive change keeps your code out of the hands of your customers, and code that's in the lab doesn't do your customers any good. Disruptive change takes several forms:

• Unchecked scope creep can quickly derail any project. You must consciously mitigate each change in scope, and do so with minimal disruption to your team and schedule. That usually means pulling features out for each one that you add.

• Changes that are outside the central purpose of a project reduce focus. This kind of disruptive change often deals more with infrastructure and middleware than with end applications. For example, I have seen customers build messaging into their persistence frameworks, or business logic into their user interfaces. These types of short-term compromises usually backfire.

• Changes outside of the normal release schedules disrupt a team, and changes that happen very late in an iteration (for example, after a code freeze) are especially disruptive. In general, you improve your ability to change by shortening iterations rather than forcing unnatural change into an ongoing iteration. Figure 3-2 shows the cost of change at each step in the development cycle. The sawtooth pattern is characteristic of the cost of change in an iterative development process. It's better to have the customer wait for the next iteration.

Figure 3-2. At the end of each cycle, especially after a code freeze, change gets more expensive

In general, certain types of changes cause more chaos than others: late changes, large changes, and shifts in focus. The reality, though, is that you're going to have change, and unless you're both disciplined and lucky, you're going to have to deal with some late change. The rest of this chapter, and this book, deals with adapting to change.