Tom DeMarco has written a thoughtful and introspective article on software engineering (PDF). In that, he questions some of his early work on metrics, wondering if it is still relevant. He suggests that there was too much focus on time and budget deadlines when the more important goal should have been making great software.
strict control is something that matters a lot on relatively useless projects and much less on useful projects. It suggests that the more you focus on control, the more likely you’re working on a project that’s striving to deliver something of relatively minor value. To my mind, the question that’s much more important than how to control a software project is, why on earth are we doing so many projects that deliver such marginal value?
DeMarco’s article can be interpreted in different ways, but I think he, like many people, is trying to reconcile how to find a balance between getting results from a software project and managing unpredictable human beings. Many software engineering principles find their inspiration from methodologies used in other engineering disciplines and industries where the “human effect” has less of an impact on project success.
Let’s take a software engineering concept like metrics. They are very useful, but they suffer from many problems:
- Measuring something changes the behavior of the team with regard to that metric. If you measure bug count, it will decrease, but perhaps at the expense of something else that is not measured.
- Collecting and analyzing metrics takes time and money. As DeMarco points out, controlling a software project is more useful when the marginal value is less, but if you spend money on metrics, how much ROI do you get?
- Metrics collection affects the human relationship aspect of team dynamics. How do you balance your trust in metrics with your trust in the delivery capability of the team?
So while they provide valuable insight into the present state of the software project, they have a distorting effect. But if you throw out metrics entirely, you are flying blind with no idea about the quality or completion of the project. So there has to be a happy medium somewhere.
The problem with the formalized concept of software engineering is that it gives you the illusion of control. The project manager assumes that by following a set of processes, they will achieve the goals of the project. If there is any deviation, it has to do with not follow the methodology to the letter. Something was missed, or something was not done 100%.
We can see this at work with how people approach CMMi, Agile, PMP or any other methodology. Each has its own merits, but the implementors (project managers, PMOs, quality teams) want complete adherence to the methodology (straight or tailored) and deviations are treated as non-comformance. If a project fails, it is always a mistake of not following the principles properly.
And like DeMarco, I feel that this is wrong. No methodology can give you the whole truth. There are methods and techniques to help improve software quality and productivity. But there are never any silver bullets and we have to let go of assumptions that we can find sure-fire ways of producing perfect software. As the software field continues to innovate, we have to also innovate in ways of managing teams and producing better software.
Finally, read DeMarco’s analogy about controlling the teenager again. Many project managers and team leaders commit exactly that mistake – treating their team as a bunch of teenagers that must be controlled, measured and made conformant to a set of policies and processes to make them successful. What hubris! Why not trust them to do the right thing?