In truth, a good case could be made that if your knowledge is meagre and unsatisfactory, the last thing in the world you should do is make measurements; the chance is negligible that you will measure the right things accidentally.
Last week I drove to Los Angeles with my wife, two kids, my mother-in-law and her sister in our not so eco-friendly SUV. Hilarity ensued, but that’s not the point of this post.
I don’t usually drive this car. Until recently, most everything in my life was in about a 5 mile radius, work, play, whatever. The SUV is ‘her’ car; my wife drives it to where she does research and home most everyday. Occasionally, we all get in and go somewhere exciting, like grandma’s.
You are starting to wonder what is the point, and I’m hoping I’m about to make some.
This late model SUV has a speedometer, a tachometer, and in addition has a computer that is estimating instantaneous MPG and average MPG since the last fillup, since the beginning of the trip, since the epoch, etc.
On the way to LA, with this SUV stuffed full of people and random stuff, I averaged just over 20 MPG at ~80 MPH. On the way back, I averaged 25.6 MPG with the same people and even more stuff and nearly identical MPH.
On the way there, I kept watching the gauges and thinking ‘these rolling hills are killing my gas mileage’. On the way back, I was optimizing the speed and acceleration patterns, only dipping below 20 MPG on the steepest inclines.
If one rides a bike on hills, he or she figures this out pretty fast. There are certain speeds you can hit a hill that can be maintained with less effort than it will take to go slower, all this is based on fitness, the equipment and the hill. Also, acceleration uphill is fairly expensive. Your body figures this stuff out because energy expenditure and efficiency have consequences, and the feedback is rapid.
In an automobile, I doubt I ever would have figured it out without the gadgetry.
You can’t manage what you can’t measure.
What does this have to do with software? Velocity is a commonly used idiom in project planning. I’ve seen velocity measured different ways in practice, and seen it’s measurement discussed in many more.
But I’ve never really seen efficiency measured with relation to velocity. The only time efficiency is considered is with respect to getting more velocity.
I’ve never seen anyone in a planning meeting ask, how can we maintain this velocity more efficiently? Is this velocity the most efficient? Over the life of any decent sized project, this seems like it would be important.
(Aside: The XPers might, as they have a notion of sustainable pace, but I’ve never been in a pure XP setting. I’m starting to think they only exist in legends or they are like the Jedi scattered by the clone wars trying to cultivate the force in swamps and deserts… I’ll be at Agile 2008 this week, so I’m hoping to come home with some new Jedi minds tricks.)
How many miles per gallon are you getting? Are you losing MPG to the rolling hills?
Perhaps the more important question, how would you know? What do you measure? (The instantaneous estimate feedback was key for me, hmm…)