Although the point of this column is to discuss “where the rubber meets the road” of software development rather than theory, if you read SD Times, you are most likely managing a software development team or teams. As endlessly challenging as code is, dealing with people is, by far, the harder part of developing software products.

Once upon a time, I had a certification for Project Management from some Very Prestigious Project Management Organization. I knew all about PERT and Gantt charts, critical paths, and resource balancing. I won’t say that knowledge of such things is useless in software project management, but they are not nearly as important as these five issues:

The mythical man-month
Code exists primarily in the mind of the developers. What runs on the machine is a (hopefully) faithful transformation. Creating and evolving code that produces value to end users is primarily a communication problem. The more people are involved, the more overhead there is in communicating things clearly, accurately and in a consensus. In “The Mythical Man-Month,” Fred Brooks formulated the law: “Adding manpower to a late software project makes it later.”

What was true in 1975 remains true in 2015. Your ability as a software project manager critically depends on your managing the quite inelastic rate at which your team can work.

No silver bullet
I reference Brooks in this column frequently for another work of his. His paper “No Silver Bullet—Essence and Accident in Software Engineering” relates closely to the nuts-and-bolts world I generally examine. What kind of productivity gains can we hope to achieve with excellent tools and techniques? Brooks argues, in this 1986 paper, that no single tool or technique was likely to produce an order-of-magnitude improvement in productivity in the next decade. Again, what was true 30 years ago seems to hold today.

Developers are often uncritical in their advocacy for a new technique: It solves one problem well, and they extrapolate that all their problems will be solved. Not only is this forgetting the “software is about communication” point made a moment ago, it’s almost certainly wrong for even the task of coding, which has enough variety to confound even the most elegant of approaches.

High-level management is even more prone to silver-bullet thinking. Software teams are expensive, and I’ve never known a team that hasn’t wasted at least a sprint confidently implementing exactly the wrong thing. As a software manager, you have to be the skeptic and, while accepting that things can improve, they probably won’t improve all that much.

Estimation trouble
If devs are uncritical about their tools, they are positively delusional in estimating their tasks. All software project managers have, at some early point in their career, laid a bunch of dev-provided estimates in a row (or perhaps in a fancy Gantt chart) and naively relayed the (very poor) estimate to upper management only to have it turn into a (very fixed) deadline.

Estimation is so difficult to get right that there is a vocal contingent that says that software project managers should refuse to provide them. While I agree with the idea of incrementally improving a potentially shippable product, I do not think it’s reasonable to expect that estimates can be eliminated. Companies have legitimate budgeting demands and, having worked at an observatory that synchronized the delivery, use, and evolution of scientific instruments on two 300-ton precision instruments, I’ve become skeptical of the idea that software development is so uniquely difficult that it should be exempt from scheduling.

I’ve found function-point analysis to be the best technique for large-system estimation and group-sourced techniques (such as Delphi or planning poker) best for small-scale and specific tasks. My favorite books on the subject are “Software Estimation: Demystifying the Black Art” by Steve McConnell and “Function Point Analysis: Measurement Practices for Successful Software Projects” by Garmus and Herron.

Dancing with bears
While Gantt and PERT charts are misleading in software projects, traditional project-management training does provide a keen understanding of “risk.” I’m putting that in quotes to emphasize that, in project management, risk is an entire area of study, not just the simple exposure to danger.

In their short, invaluable book “Waltzing with Bears: Managing Risk on Software Projects,” DeMarco and Lister define risk as “a weighted pattern of possible outcomes and their associated consequences.” When I first began managing software projects, I thought my job was to come as close as possible to a particular result given the constraints on hand. That’s wrong. The result of a software effort (rarely the “outcome” because software projects don’t ever really end) is never what was envisioned at the beginning. It may be worse, it may be better, but it will be different, and it will be used differently and it will have unforeseeable effects. Software project management is risk management.

No matter what they tell you, it’s a people problem
But having said that, the final and most important rule of software project management is that it’s not really about project management at all. Nor is it about libraries, programming languages or technology stacks. Weinberg’s Second Law of Technical Consulting is “No matter what they tell you, it’s a people problem.”

The definitive book on the issue of peopleware is by DeMarco and Lister again. Conveniently, it’s called “Peopleware.” And although some of its advice goes against today’s fads (such as the importance of offices with closing doors, as opposed to the current fashion of open floor plans), I think its advice is spot on.

There is much more to software project management than these five issues, but understanding and optimizing them will put you ahead of the majority of professional software project managers. You’ll be less stressed, your development team will be happier, and most importantly, your customers will have the best chance of receiving value from your team at the highest possible rate.