Page 214 -

potential problems that it might create. In other words, it’s not enough to show that the
benefits of a change outweigh its costs on an organizational level; if people do not see how
a new tool or technique personally benefits them, they may see it as a burden with no
benefits and will be resistant to adopting it.
Resistance to change is not necessarily a bad thing. For example, when a project’s scope or
requirements are repeatedly changed, delays and defects usually result. In Chapter 6, a
change control process was introduced to make sure that changes are only made after
their costs and benefits have been fully explored. If it is important for projects’ changes to
be controlled, it is even more important that an organizational change is made only after
its costs and benefits are well understood. It would be difficult to work in an organization
that welcomes any change from anyone, without considering the impact of that change.
It makes sense to be prudent in evaluating the nature of changes made to the way you
build software. Too drastic a change can cost you your project. Everybody on the team
needs to understand why new practices are put in place, and each person should feel like
he understands how his role fits into the big picture. If the way the team builds software is
constantly being “improved,” it can become too difficult for each person to keep track of
his day-to-day tasks, and people can lose their sense of purpose. This can lead to prioritiza-
tion problems, quality problems, and almost certain delays.
Yet despite the fact that changes can be hard to introduce, you will want to introduce new
tools, techniques, and practices. But even when you are fully prepared to show that the
benefits outweigh the costs, people in your organization may still resist those changes.
This can lead to a very frustrating situation. You may make a great case for a change: there
is a real problem and you have the evidence to support it; many people, both inside and
outside your organization, see the problem. The senior managers and the project team all
agree that there is a problem. But when you start suggesting changes that address this
problem, everyone gets uncomfortable. As each person starts to think about how he
would have to change how he does his own job, some will simply start to resist any
change. They may resist it because it would require learning a new way of doing things,
because it would require them to do more work, or just because it is different.

And even when you convince others of the need for a change, it can sometimes be difficult
to prove to the people in your organization that adopting a particular tool or technique will
really solve the problem. Often, people will question whether they should go through all of
the pain of changing, without knowing for certain that the change will result in a real solu-
tion. It can be very difficult in this situation to convince them otherwise.
We Already Build Software Well
Denial is a common response to change. You may have identified a glaring problem, but
people around you fail to even recognize it (or simply refuse to acknowledge it). Many
professional software engineers and managers have never experienced a project that did
not have enormous delays and serious problems; it’s often assumed that this is just part of
how software is built. After all, they usually delivered something—most projects were

206 CHAPTER NINE