Software Engineering Reality: Momentum

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

imageNewton’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?

Comments

Matt Turner said on 6.16.2014 at 11:37 PM

Yep momentum is the key to most success. I'd say the biggest factor is attitude of those on the team. Even if it's a team of one.....especially if it's a team of one. If the team believes they can do it and more importantly committed to doing it, they tend to get it done. Doubt is the only thing that kills that.

If you have one naysayer(i'm not talking about someone who just has a differing opinion of course) that adds doubt to the team. It's seven worse when that naysayer is the back of your own mind. It can be deadly. Because that doubt has momentum of it's own. Unfortunately, I find the acceleration of momentum of doubt far exceeds the momentum of success. This comes from human's innate fear of loss. So, in my opinion it's something that must be nipped in the bud.

A smooth running team who has settled on a set of ideals will be a positive momentum feed back loop, when left mostly unmolested. As long as managers can keep from tinkering with it too much it seems to constantly improve and exponentially grow. Even better one positive team can infect other teams with their momentum as well.

I guess my point here is that there are a variety of "Momentums" that can affect a project. Thoughts?

Cristian said on 6.27.2014 at 9:16 AM

There's an excellent talk by Greg Young about getting productive in an unknown environment.

https://vimeo.com/43624436