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.