Facts of Software Engineering Management

Robert L. Glass explains why a software manager can't forget about the most important facts  like people are important, technical hype does more harm that good, and complexity is, well, complex.

Purchase this book through the end of January and receive four exclusive sample chapters from forthcoming books by some of technology's greatest luminaries. For more information, check http://www.expectsomethingbetter.com.

This chapter is from the book

This chapter is from the book

About Management

To tell you the truth, I've always thought management was kind of a
boring subject. Judging by the books I've read on the subject, it's 95
percent common sense and 5 percent warmed-over advice from yester-decade. So why
am I leading off this book with the topic of management?

Because, to give the devil its due, most of the high-leverage,
high-visibility things that happen in the software field are about management.
Most of our failures, for example, are blamed on management. And most of our
successes can be attributed to management. In Al Davis's wonderful book on
software principles (1995), he says it very clearly in Principle 127: "Good
management is more important than good technology." Much as I hate to admit
it, Al is right.

Why do I hate to admit it? Early in my career, I faced the inevitable fork in
the road. I could remain a technologist, continuing to do what I loved to
dobuilding software, or I could take the other fork and become a manager.
I thought about it pretty hard. The great American way involves moving up the
ladder of success, and it was difficult to think of avoiding that ladder. But,
in the end, two things made me realize I didn't want to leave my technology
behind.

I wanted to do, not direct others to do.

I wanted to be free to make my own decisions, not become a "manager
in the middle" who often had to pass on the decisions of those above
him.

The latter thing may strike you as odd. How can a technologist remain more
free to make decisions than his or her manager? I knew that, from my own
experience, it was true, but it was tough explaining it to others. I finally
wrote a whole book on the subject, The Power of Peonage (1979). The
essence of that bookand my belief that led to my remaining a
technologistis that those people who are really good at what they do and
yet are at the bottom of a management hierarchy have a power that no one else in
the hierarchy has. They can't be demoted. As peons, there is often no lower
rank for them to be relegated to. It may be possible to threaten a good
technologist with some sort of punishment, but being moved down the hierarchy
isn't one of those ways. And I found myself using that power many times
during my technical years.

But I digress. The subject here is why I, a deliberate nonmanager-type, chose
to lead off this book with the topic of management. Well, what I want to say
here is that being a technologist was more fun than being a manager. I
didn't say it was more important. In fact, probably the most vitally
important of software's frequently forgotten facts are management things.
Unfortunately, managers often get so enmeshed in all that commonsense,
warmed-over advice that they lose sight of some very specific and, what ought to
be very memorable and certainly vitally important, facts.

Like things about people. How important they are. How some are astonishingly
better than others. How projects succeed or fail primarily based on who does the
work rather than how it's done.

Like things about tools and techniques (which, after all, are usually chosen
by management). How hype about them does more harm than good. How switching to
new approaches diminishes before it enhances. How seldom new tools and
techniques are really used.

Like things about estimation. How bad our estimates so often are. How awful
the process of obtaining them is. How we equate failure to achieve those bad
estimates with other, much more important kinds of project failure. How
management and technologists have achieved a "disconnect" over
estimation.

Like things about reuse. How long we've been doing reuse. How little
reuse has progressed in recent years. How much hope some people place (probably
erroneously) on reuse.

Like things about complexity. How the complexity of building software
accounts for so many of the problems of the field. How quickly complexity can
ramp up. How it takes pretty bright people to overcome this complexity.

There! That's a quick overview of the chapter that lies ahead.
Let's proceed into the facts that are so frequently forgotten, and so
important to remember, in the subject matter covered by the term
management.