In a recent post on Building Better Software, I wrote about why developers should care about project management. But I think it's worth making the opposite case: why project managers should care about development.
It seems kind of crazy, like I'm suggesting that there are software project managers out there who might not care about development. And that's exactly what I'm suggesting. Certainly, there are a lot of really fantastic project managers out there who really understand the ins and outs of a software project. But I've definitely run into more that I'd care to admit who didn't really seem all that interested in the actual day-to-day work that developers do. And I think it really affected their projects negatively.
I've spent a lot of time over the years training project managers, and one thing I've heard from many of them is that a good project manager can manage anything. In other words, a project manager doesn't need to know anything about software development in order to manage a programming project. He just needs to know about project management, and those skills will allow him to make sure the project comes out on time, on scope, and on budget, with sufficient quality.
This, to me, is seriously flawed thinking, and borderline insane. Imagine a general contractor who doesn't know how to use power tools or know anything about carpentry, flooring, or anything else about construction. Would you hire this person to add a wing onto your house? How would he even be able to judge whether or not the project is going well?
Yet a lot of software project managers know precious little about software development. That's why Jennifer Greene and I included a chapter on programming practices in our first book, Applied Software Project Management. In a way, I feel like it's our way of drawing a line in the sand and saying, "Project managers need to know at least this much about programming." We cover some really important (but basic) practices: using a version control system, unit testing, refactoring, continuous integration, and holding effective code reviews and design reviews.
Here's a quote from the beginning of the chapter on programming practices. I think it does a pretty good job of expanding on exactly why I think these things should matter to every software project manager.
There's a famous quote attributed to Kent Beck, a widely respected software engineer who's responsible for many advances in the field: "I'm not a great programmer; I'm just a good programmer with great habits." This chapter is about introducing some of those great habits. A good programmer who adopts these habits will build better software.
Programmers spend their time designing and building software, and all of their project work revolves around the source code. But many programming teams find that they lose control of their own code. Sometimes they lose track of the changes that they make; new additions might occasionally disappear, and old bugs routinely pop up. They might lose control of the design of the code, finding that no matter how much care they put into designing the software well, they still end up with messy code that's difficult to maintain. Some programmers have never known any other way, and don't realize that these problems can be eased. A project manager can improve the code by helping the team adopt good programming practices.
While many development problems originate outside of the programming team, there are some basic changes that the programmers can make that will improve the quality of the code they produce. Most teams, even ones with skilled and talented programmers, are vulnerable to the same design and programming problems. These problems can be addressed with a few basic tools and techniques -- which can often be put in place entirely within the programming team, without involving anyone else in the organization.
— Applied Software Project Management, p132