In a discussion recently with James Shaw, one of our engineering department Vice Presidents, we explored the concept of momentum as it pertains to computer programming.  The topic arose in one of the many times we struggled to provide a good-enough estimate.  This estimate was for making a change to a software system we were inheriting.  A code base we had not explored, and a code base which we had never modified, built, or tested before.   As you can imagine, and estimate in this environment is completely trash.  Similarly, I would imagine, to an estimate given for what it would take to open back up the police station in Haiti after the devastation several years ago (without first visiting the region).

When thinking about how we could begin setting expectations for how long a software change might take, we recalled the anecdote of one of the folks at the client saying “it took Bob about a week the time we had to do something like this before”.  While useful information, providing an estimate of a week would be sure disaster.  As we pondered why this was true, we discovered an appropriate way to describe the force at play.

MOMENTUM

Newton’s first law states that a body remains at rest or in uniform motion in a straight line unless acted upon by a force.  It’s amazing how this applies to software engineering as well as many different human endeavors.  In fact, I hear momentum referred to during sporting events quite frequently – as when an interception kills the momentum of a scoring streak by the opposite team.

James and I analyzed momentum in software development and for the purposes of providing estimate.  We remembered the many times in our careers when nontrivial enhancements to software were able to be completed in very short periods of time and what the factors were.  And we also remembered the times when seemingly trivial enhancements took inordinate amounts of time.  A common element of each was the presence or absence of momentum.  That is, when a software engineer brain has been engulfed in a code base and problem set for an extended period of time, accomplishing many tasks, there is good momentum.  The marginal effort of each successive task decreases until it approaches some minimally viable floor of effort.  That is, when going 100 MPH on a software problem, each mile marker passes by relatively quickly.  In contrast, when starting from a stand-still, the first task absorbs the cost of acceleration. 

In normal circumstances, like context switching, momentum can be gained quickly.  In cases where we are taking over a software system written by unsophisticated teams, gaining momentum can be much more difficult.  For instance, environment friction can be a huge factor in the cost of gaining and maintaining momentum.  How long does it take to prepare the environment for programming?  How long does it take to integrate changes and prepare for testing?  What is involved in understanding where to make changes?

We did not come up with an actual answer for how to estimate a change to a previously unknown code base, but we were able to articulate the momentum factor at play.  Have you, dear reader, noticed this factor at work in your environment?  What builds/kills your momentum?