Wednesday, July 18, 2007

Don't Build for the Future

Toward the end of Dreaming in Code, there is this quote from Mitch Kapor:

We've constantly over-invested in infrastructure and design, the fruits of which won't be realized in the next development cycle or even two--that is, not in the next six or twelve months.  You pay a price for that in a loss of agility.  The advice I would give is to do even more of what we've been doing in the last couple of years, which is to sequence the innovations, stage things, and be less ambitious.  Do not build infrastructure...except insofar as you need to meet the goals of the next year.  I'm more and more feeling like the art here is to do agile development without losing the long-term vision.

He's basically mirroring Linus Torvalds' advice I wrote about earlier.  If you take into account too much of your future plan, you'll failure to deliver the present version.  It's better to write flexible code that can be refactored in the future than to write code which has the future built in already.  If you have future ambitions for your program, there are good reasons you aren't planning it all for the current release.  You've decided that it is too much to get done in the timeframe allotted.  If that's the case, trying to do work that makes it possible means pulling much of the complexity from version 2 back into version 1.  That can only make version 1 more complicated and increase the time it takes to write.  It also deprives you of the ability to incorporate your experience into the design of those portions.  It's better to leave out the complexity and have more experience when you do implement them later for version 2.

Following proper design techniques can help a lot here.  If you following the major tenets of object oriented design, your code will have the required flexibility to make the changes you want for the second version.  If it is not, you can always refactor the flexibility in.  If you build that complexity now, you delay your project and probably got it wrong anyway.  The Chandler team spent a lot of time implementing functionality which was later replaced as they better understood the problem domain.

In the Innovator's Dilemma, Clayton Christensen gave some advice to startups (whether in big companies or working on their own).  He told them to always save enough funding for a second release.  His reason is that you never really know your market until you are actually selling a product into it.  I think the same holds true for software.  You never really understand what your program is supposed to be until you've written the first version.  Only after you get your product into the wild will you come to understand what it should have been.  This new understanding will inform your decisions for version 2 of your project.  Often, this new understanding will be radically different from what you originally intended.  Delaying investments is the best way to ensure that your energy is focused in the right places and that your implementation is best suited to achieving the updated vision.


  1. Yeah, you build the brooklyn bridge version 1.0, next the version 2.0 alpha... and so on and on and on...
    And you call this thing "design"

  2. No.  When you are building the brooklyn bridge, you just build the bridge for cars and people, you don't try to also build in the capability to handle flying cars (or some other future item).  You build for what your requirements are today.
    Here is a local example in the world of civil engineering.  In Seattle they built a bus tunnel under the city streets.  At the time, they also added tracks for light rail in the tunnel because they knew they wanted to build light rail later.  Adding this feature took extra time and money.  This year they are finally getting around to actually building the light rail.  Unfortunately, the tracks they put in won't work.  Now they have to rip out the old tracks and put down new ones.  More money and more time.
    Building too far ahead in software can get us into the same problems as the Seattle bus tunnel.  It's best to only build for what we know we need.

  3. So true regarding where startups need to be focusing their attention. The motto that companies like Goggle right on through to ones like ours are adopting "perpetual BETA". That's not to say its buggy code, that's for the alpha round, its stable test cases to progress the platform.

  4. "No.  When you are building the brooklyn bridge, you just build the bridge for cars and people, you don't try to also build in the capability to handle flying cars (or some other future item).  You build for what your requirements are today"
    A very very long "today" ;) it was started in 1883!!!

  5. Well, if we're going to be technical, construction started in 1870; it opened for use in 1883.

  6. From the same article:
    "In 1950, the streetcars also stopped running, and ***the bridge was rebuilt to carry six lanes of automobile traffic.***"
    (my emphasis)

  7. My email overfloweth with great links. Here is a 2nd edition of squeezed links this month. How To Piss Off Development - The Cranky Product Manager shows us the sure-fire way to piss off a development team
    Don’t Build for the Future - Simple ti..