Page 219 -

writing code. Any project activity that takes place before the programmers begin writing
code simply amounts to “spinning our wheels,” and the goal of all early project activities
should be to get the programmers doing the “real work” as quickly as possible.
A manager in this sort of organization will typically think that if she just adds more pro-
gramming hours, a project that seems to be failing will get back on track. Since program-
ming is the main activity in the project, all project problems amount to programming
problems. In fact, there are project managers who believe that all they need for a successful
project is a team of top-notch programmers. They wonder, “Why do we need to quadruple
our documentation by creating schedules and project plans and change control proce-
dures?” After all, it’s been shown time and time again that a great programmer is 10 times as
productive as a mediocre one. Isn’t it enough to pay top dollar getting the very best pro-
grammers and setting them loose on the problem? Why all the extra “bureaucracy”?

In reality, programming is usually less than 40% of the effort on a successful project. Most
project problems are caused by the team not understanding what it is that the software
should do. Estimation problems happen when the team members don’t explore all of the
assumptions that they are making and, as a result, don’t have a handle on what information
is known and what is unknown. Project planning goes wrong when the scope creeps, or
when there are problems that could have been foreseen. When bugs are found in the soft-
ware, often it’s not because the software is broken; the software is usually working exactly
as the programmer intended it to work, it’s just not doing what the users need it to do.

The solutions to these problems do not involve programming. But, to some people, any
action that the team takes that does not directly relate to programming is “bureaucratic.”
Planning the project, writing down requirements, and holding inspection meetings is seen
as just pushing paper around. There may be a project schedule, but this is just used as a
tool to help the rest of the organization understand what it is the programmers are
doing—in other words, the schedule is created by asking the programmers their opinion,
and the project manager’s job mostly boils down to simply reporting that opinion to the
rest of the organization. (Even worse, of course, is the project manager who simply makes
up the schedule out of thin air, or bases it solely on the boss’s expectations.)
When the project manager’s role is reduced like this, there is usually an implicit assump-

tion that a schedule is just a guess, and an expectation that it will almost certainly slip. At
least the project managers and other software engineers believe that it’s implicitly
assumed. Unfortunately, this is a dirty little secret among the engineering team. The rest
of the organization takes these estimates and schedules at face value. They believe that the
team made a real commitment, and they make important decisions based on what they
believe is a real date. This leads to a general feeling of distrust between the software engi-
neering group and the rest of the organization. It all starts with the project manager’s mis-
taken attitude that it’s just not possible to estimate a project accurately, and that you just
can’t predict what’s going to happen when the team starts building the software. (See
Chapter 3 for more information on how to estimate a project accurately.)

UNDERSTANDING CHANGE 211