Page 248 -

Some senior managers feel that they have navigated more difficult problems than whether
or not to put the code under source control or add another round of testing. These things
seem like details to them, and they don’t feel that they need to read a book to figure them
out. To someone with this attitude, the very fact that you are concerned about these
“details” makes you seem like an alarmist—you are up in arms about something that they
consider very minor. Or, even worse, they feel that they have done a fine job of building a
software organization, and are insulted that you think that you can make it better by
introducing changes.
If an organization is in the software business, the people running that organization need to
understand the details of making software. Making those decisions is uncomfortable for a
senior manager with little software experience: it is hard to make sound decisions about
building software when one has only a simple, high-level view of software design, pro-
gramming, and testing.

One common senior-management response to this problem is to attempt to delegate—
probably to you, since you have read a book about it and seem to know what you are talk-
ing about. Unfortunately, this is a shallow commitment that can cause its own problems. If
your boss does not understand the goals of the improvements you want to make or the
reasons behind them, he will not make consistent decisions. The actions that you take in
implementing new practices on your project will impact other people: they will create
additional work for some of them, and many will perceive that you are taking away some
of their power, flexibility, or freedom. And, in some poorly run software organizations,
there may be people assigned to software tasks who are not very good at those tasks; they
might prefer not to have their work measured or analyzed. If they see you as an inter-
loper, they will complain to your boss. If he does not understand why you are doing what
you are doing, all he will see is conflict—conflict that you created with the changes that
you made. Since he did not take the time to understand the benefits of your actions, he
will simply blame you for making changes and causing conflict. Your improvement effort
will grind to a halt.

The solution—and it is not an easy one—is that upper management must be better edu-
cated about the details of your project. The person who has the authority to tell you (and

everyone else on your level) to undertake a project should understand the purpose behind
every step in the software process. This means more than just understanding that software
needs to be designed, developed, and tested. He needs to know why the software is being
developed that way.
It means that if, for example, you are trying to implement inspections, then the senior
manager must understand what an inspection is, what is being inspected, what kinds of
defects it will find, why those defects are there, who needs to attend the inspection meet-
ings, and what will happen if the inspection is skipped—and he needs to understand this
before the inspections are implemented. He must be sold on the idea. If he does not agree
that this is the most efficient and effective way to develop software, he will fold the first
time someone decides that inspections are “bureaucratic,” unnecessary, or somehow get-

240 CHAPTER TEN