You can’t control what you can’t measure

From the person who is attributed with the quote “You can’t control what you can’t measure”, comes an article called “Software Engineering: An idea whose time has come and gone”.

Interesting points from the article:

I’m suggesting that first we need to select projects where precise control won’t matter so much. Then we need to reduce our expectations for exactly how much we’re going to be able to control them, no matter how assiduously we apply ourselves to control.

In support of the above, Tom provides the following example:

To understand control’s real role, you need to distinguish between two drastically different kinds of projects:
- Project A will eventually cost about a million dollars and produce value of around $1.1 million.
- Project B will eventually cost about a million dollars and produce value of more than $50 million.
What’s immediately apparent is that control is really important for Project A but almost not at all important for Project B. This leads us to the odd conclusion that 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.

I really liked his analogy of trying to apply “you cant control what you cant measure” to your teenager’s upbringing.

Most things that really matter—honor, dignity, discipline, personality, grace under pressure, values, ethics, resourcefulness, loyalty, humor, kindness—aren’t measurable. You must steer your child as best you can
without much metric feedback.

Towards the end he writes:

So, how do you manage a project without controlling it? Well, you manage the people and control the time and money. You say to your team leads, for example, “I have a finish date in mind, and I’m not even going to share it with you. When I come in one day and tell you the project will end in one week, you have to be ready to package up and deliver what you’ve got as the final product. Your job is to go about the project incrementally, adding pieces to the whole in the order of their relative value, and doing integration and documentation and acceptance testing incrementally as you go.

Sounds like he thinks going Agile is the answer!

Note: Jeff Atwood had an interesting commentary on the above article and the comments are equally interesting. http://www.codinghorror.com/blog/2009/07/software-engineering-dead.html