Miles Per Gallon

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.

George Miller

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…)

7 responses to “Miles Per Gallon

  • James Turnbull

    I am also interested in the conjunction of velocity and quality. Too many projects measure velocity without monitoring quality. Doesn’t matter how much velocity you have if it doesn’t deliver the functionality.

  • Working Together… with Techology « fate = will && choice || circumstance

    […] not even sure where that would lead. I do know that new information enables optimization, both specific and systemic improvements. (but hopefully not draconian notions of productivity… […]

  • Israel Gat

    in a recent Cutter Consortium Executive Update, Jim Highsmith has made the following observation with respect to velocity and quality going hand in hand:

    “A number of quantitative studies done in recent years by Cutter Senior Consultant Michael Mah attest to the higher quality of many agile projects and the positive impact on scheduling.”

  • stochasticresonance


    (I appreciate the comment)

    I might not have made it clear in my writing, but what I’m pondering is sustained efficiency as much as velocity.

    I believe anyone who works with technology would recognize that higher quality enables higher velocity.

    To extend the auto analogy, the engine, brakes, transmission, steering and tires can all help increase the safely achievable speed.

    But for any given automobile, the style of driving effects not only the velocity but also wear and tear.

    In some situations, such as a race with a clear finish line, ‘winning’ might justify driving without concern for anything but that goal, but it costs quite a bit to maintain a race car. Sometimes that is a justifiable cost.

    The question becomes what you are trying to optimize and what you are aware of. If you are just trying to get across town, do you know the right velocity to time the red lights or do you cycle between acceleration and braking because you are ‘in a hurry’. Both approaches get you to the same place at roughly the same time.

    One has a much lower long term cost, but it is difficult to measure that cost moment to moment.

  • Alan Shalloway

    If you don’t understand the theory (aka rules/laws) underneath product/software development, measurements are very likely to be misleading. Unfortunately, several leaders of the Scrum community resist that such a theory exists. If you embrace theories that have been demonstrated by decades of work that support product development, then measuring things like cycle time, delays from error to detection, and a couple of others, can be very useful.

    Software development is a very complex endevour. It can be hard to understand, but that does not mean it is not understandable.

  • stochasticresonance

    I’d love to see the rules/laws articulated but I believe trying to codify them is an exercise in futility.

    Please prove me wrong…

    the Tao that can be spoken of is not the Tao…

    • Alan Shalloway

      see reinertsen’s work – managing the design factory, and principles of product development flow
      Womack and Jones’ – Lean thinking
      These have much of it.

      True that our descriptions of what is going on is not exactly the same as what is going on. But they can still be useful.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: