Facts of Software Engineering Management
- About Management
- People
- Tools and Techniques
- Estimation
- Reuse
- Complexity
This chapter is from the book
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.
References
Davis, Alan M. 1995. 201 Principles of Software Development. New
York: McGraw-Hill.
Glass, Robert L. 1979. The Power of Peonage. Computing
Trends.