One night in Le Chable, Switzerland, sixteen years ago, I looked around to the four friends with whom I sat at the train station bar and told them I’d changed my mind. We were waiting for the Saint-Bernard Express, which would take us down valley to Martigny and eventually back to school and life. But it was dumping outside. Verbier's peaks loomed above us in the snowing dark. The skiing we’d just had didn’t compare with what was to come, and I knew I had to be on the lifts that next day. So I finished my beer, tore up my ticket, and told the crew that I was staying for more. They could do what they wanted but when tomorrow came, I’d be skiing the deep.
My decision-making framework changed when back home in Boston I met the woman who would become my wife. We dated, started depending on one another in the plans we made, and eventually moved in together. In coupling up, each of us introduced the others’ history, friends, and preferences into our own life, and we each internalized the new reality of a larger context for our acts and choices. We joked that in socializing with other couples, we’d moved even beyond an additive model (1 + 1 = 2) to an exponential one (2 + 2 = 12, see below) and that this was slowing us down. Basically we’d compounded relationships and dependencies. We’d also expanded the resonance of our decisions and actions.
This is software development. And this is why an intense and ingrained appreciation of feature baggage and compounded interdependence is critical to a product’s successful growth. “How long would it take to…” and “What if we just…” are a couple of the ways clients can introduce requests for nominally-incremental new features. The problem with these setups is that they usually don’t account for either the requested feature’s backstory (its history, friends, preferences, as it were) or the product’s maturity (its number of existing relationships and dependencies). As Kris Gale, VP of Engineering at Yammer puts it:
The work of implementing a feature initially is often a tiny fraction of the work to support that feature over the lifetime of a product… [And] what might take two weeks right now adds a marginal cost to every [emphasis added] engineering project we'll take on in this product in the future.
Sure, we’ll need to borrow a truck and get the sofa up the stairs to move in together. But let’s focus on the bigger picture of that ‘together’ piece, and what this implies for us as we go forward.
Programming Languages and data structures are only a piece of the puzzle. Consider the following representation of phases and components involved in taking a B2B solution to market. Code for the core, requested features represents just ten percent of the How-Long/What-Will-it-Take question. The rest of the effort goes to ensuring that we solve for the right problem, in the right way, that gets tested, then introduced to end users, monitored, and optimized. Together these make up the backstory; they’re the parts that ensure that when the feature moves in, the household remains long-term viable. To ignore them is to embark on an endless feature chase whose ‘product’ is more dormitory than bedrock for the future. See L’Auberge Espagnole for how this scenario plays out.
So let’s not build. At least not until we’re sure our foundations are ready, and we’re solid on the ninety percent that isn’t about programming. Let’s recognize that as our product does grow we’re going to slow ourselves down simply by the nature of the dependencies we create. And let’s make considered decisions in sacrificing the impulse and velocity. Sixteen years after I cashed in on that Alpine dump my wife and I are out the far side of the early couples’ dinners and on to a house, three kids, and full Saturdays of soccer, gym, and baseball. It's good, and it's important that we knew it was going to be good because undoing back to the simplicity of the 1998 Le Chable train station no longer exists as a viable option.