Plan for the Present
Inspired by Joel Spolsky
Photo by Matt Artz on Unsplash
Have you ever seen the foundation of a house being poured? A crew shows up for a day with a fleet of cement trucks parading by, one by one, filling framed out wooden squares with molten gray sludge. By the next morning, you have a solid structure on which to build. It’s just about the most straightforward part of the home building project.
“Building software is very little like building houses.” — @dhh
On software projects, we tend to spend way too much time considering the foundation. We get ratholed into decisions about data models, rendering engines, and caching layers. These conversations can become all-consuming, religious wars. It’s easy to lose sight of why we’re building anything at all.
You might be wondering why deeply considering our project’s technical underpinnings is bad. After all, shouldn’t we plan for the future? Don’t we need a strong foundation in place to prepare for unforeseen eventualities? Isn’t it much cheaper to prepare for the future now than fix it later?
Well, no. But let me explain.
“Premature optimization is the root of all evil.” — @realDonaldKnuth
The obsession with ‘architecting for the future’ is dangerous because it shifts our focus. We no longer spend hours understanding the customer, learning how to solve their problem, and instead internally debate the merits of XML vs. JSON. In the hours of whiteboard debates that ensue, no code is written and no customer is better off. The best teams obsess about what customers want, and no customer wants JSON.
Technical bits and bites are tools. They are means to an end and big plans that endeavor to cover every contingency invert what matters. How would you feel about your building contractor spending all day with his crew debating the merits of framing hammers vs. claw hammers? At some point you need the kitchen sink installed!
Of course, not all planning is bad. You need to make smart architecture choices along the way to address today’s issues. Make them, document them, and get back to what matters — building something people want. The world changes under your feet, so you need to be focused on that world, not the internal machinations of your tools. It bears reminding that even the most considered plan is a guess.
“Everybody has a plan until they get punched in the mouth.” — Mike Tyson
You’ll never be able to plan perfectly for the future — so let go of that idea. We just don’t know what will happen, so planning for every potentiality creates tremendous waste. Feedback from the market and customers will change our direction — ie. we don’t know where you will end up. Technology will change and improve — ie. you can’t know what technology will be best. How many teams would have used React 5 years ago for their front end? Would Slack make the same architecture decisions as Glitch, the video game company they used to be?
“I am an old man and have known a great many troubles, but most of them never happened.” — Mark Twain
Solve today’s problem today and tomorrow’s tomorrow (if ever).
Plan for the present.
Like articles on building product? Subscribe to receive by email.
—
Further Reading:
