One of the things that's interesting about this - and is good meat for further discussion - is how to react when you find yourself on a team with someone who's clearly fighting the last war. I think it's inevitable that people end up fighting the last war, but I'd love to know if there are ways to break the cycle for someone once you see it happening.
From working with an old PHP codebase, I'd like to offer: "Design for deletion."<p>This has important differences from "design for modularity" or "design for future change" or "design so someone can swap it out", because those phrases tend to make developers go off and engineer extra stuff, under the assumption that their current paradigm for how the software operates is going to continue to be accurate even if their implementation someday needs replacing.<p>... But what happens when it's not just "this code sucks", but also "we shouldn't even have any code that's doing this task"?
Nah ... not using async, not running with tests, these aren't "let's build a Maginot line" mistakes. These are "let's not make sure our troops can run 10 miles and shoot accurately" mistakes.<p>Sure there are plenty of strategic mistakes that will doom any army or enterprise - but the biggest one, the granddaddy of them all, is only listening to half of the proverb "hire great people then get out of their way"<p>So many generals want to be sure everyone understands it is their clever tactics that won the war they forget the lessons of generals who really do - logistics and economics. Everything is subservient to getting a well fed and trained soldier with a gun in his hand at the point he needs to be.<p>For a good example look at Spolsky - hiring good people, fixing up nice offices, handing over lunch - probably there is some office manager who acts as a general problem solver for the devs and magically makes boilers and landlords and IRS problems vanish.<p>Logistics.<p>Not even big guns.
This is a problem of planning; I don't think more or more frequent planning is the answer.<p>Instead you need to make the minimum viable thing, even more minimally. Make sure the very first iteration is end-to-end usable to solve a real problem. Then you'll notice if you can't use async on the backend before putting async everywhere. You'll notice if you're testing too much. And you'll have a better understanding of your burn rate because you've done all the tasks, including the things like design and hosting and legal that can easily be forgotten.
Great article and topic. But just FYI, I don't think building a Maginot Line actually qualifies as "fighting the last war". As the author explains, the ML actually worked -- the Germans had to invade through Belgium! And had they built the ML all the way to the sea, the blitzkrieg would have failed. Perhaps a better historical military analogy would be that of Billy Mitchell and the rise of Naval Aviation (<a href="http://en.wikipedia.org/wiki/Naval_aviation#Interwar_period" rel="nofollow">http://en.wikipedia.org/wiki/Naval_aviation#Interwar_period</a>).
Anyway great lessons here -- thanks for posting.
My take away from "Do just enough" is the flip side - throw it away and start over. The second part is just as important as the first or you end up with crap prototypes in the heart of your solution. The first time doesn't have edge case handling and will be insecure, so toss it out when it starts to become a product, if not before.
> You need to watch the burn rate carefully, and have a clear plan for raising more money (either by selling to customers or raising from investors.)<p>Following the latter leads to the fatal pinch.<p><a href="http://www.paulgraham.com/pinch.html" rel="nofollow">http://www.paulgraham.com/pinch.html</a>