Code Management versus Project Management
Posted by Andy Singleton on Tue, Apr 05, 2011 @ 09:41 AM
What if we could get rid of software project management? On a big project we would save millions of dollars and a lot of boring meetings. As noted in Statistical Proof that Project Managers are Useless, project management is a difficult and thankless job. It's a task ripe for automation
PROJECT MANAGEMENT: We need project managers because we have project plans. The plan describes how multiple people contribute work to a coherent whole. Project managers coordinate this work by reminding contributors about the plan.
VERSUS CODE MANAGEMENT: On a software project, there also a coordination process running around code. As people write code, they have a process to contribute into a shared release. I reviewed some of the ways that we do that in the previous article on Four ways to manage code, simplify projects. The workflow for contributing, reviewing, and accepting code is a different way to assemble the work into a coherent whole.
In the project management case, you assemble the work of multiple people IN ADVANCE. You plan a set of tasks that fit together. In the code acceptance case, you do the work AT THE END, when you decide what code to accept. So, you do the work at different times, but you can get a similar result. The processes can be substitutes for each other.
I can't say which is more effective in general. Most projects do both. Both processes can deliver equivalent results. They both require work. However, I can think of some reasons that you might prefer to work with code.
1) It's sometimes easier to control code than people. Managers have a tough time herding smart programmers. Code, on the other hand, doesn't go anywhere when you run out of Jolt Cola.
2) Project management doesn't scale. The success of project plans declines dramatically with the size of the project. The problem is that big projects have a hierarchical structure with some sort of a boss who makes the plan, and that boss doesn't know everything, and the plan is always wrong in some way. On the other hand, code management can scale. You can imagine a project, maybe with Gerrit, which has hundreds of contributors throwing in code. You could in principle do this without hierarchy, scrums, and scrum of scrums. They might not all be going in the right direction, but at least they are figuring out the right thing to do at an individual level. So, you can see how this thought fits into the broader discussion of project scaling.