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.
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.