Startup Technical Debt

This is an interesting article but even more interesting is the series of articles that the author links to. I've been involved in several high profile products with different locations on the too much or too little debt axis. It always felt like economics could bring a more level headed viewpoint to the discussion instead of just relying on cargo cult mantras. I've skimmed and read the articles and they look like a good intro to the discussion.

As an example, I've found that most successful project have an extremely uneven distribution of debt with most of the code being glued together with bubblegum but a few critical regions having the polish of a high quality gem. Problematic projects tend to have an even quality with all parts having an equal level of 'cleanliness'. This article has some good discussion on why maintaining a similar level of quality across the system might not be a good idea: http://www.alphaitjournal.com/2009/06/cross-discovering-asse...

Technical Debt at a startup will be always be present at a large scale as long as your main mission statement is getting to market as soon as possible. Their first question is 'does the market want this' instead of 'will it scale when it reaches mass numbers'?

I always consider Facebook as a prime example. The first version may very possibly have been something hacked together in PHP, with the intent of releasing something asap that had a good chance of flourishing. Now that it has flourished, and the proof of concept is validated (with VC money), you can afford engineers who will rewrite the system the way it was meant to be, complete with a PHP compilers and custom flat file databases. The risk paid off.

Digg's technical debt served them well too. They got into the market fast, and the performance issues of the previous site wasn't nearly as big as a factor as the business domain problems they introduced. Submitters didn't mind the occasional 'invalid token' error messages nearly as much as the revolt caused by the publish of a certain encryption code.

Joel says don't rewrite from scratch. We talk about big design up front, when the design doesn't even appeal to the market. But when your product has reached a critical mass, and you have an army of talented engineers salivating to rewrite the system, all that debt is forgiven when the system is redesigned from scratch.

In my opinion, having a reasonably clean architecture is all that matters.

Not that bad: the implementation of an individual function is counterintuitive and undocumented--as long as an intuitive implementation of the function would interface with the rest of your software just the same way.

Actually pretty bad: the function has side effects that would be better off somewhere else. If this is the case, fixing this function is likely to break something, which may break something else, and so-on.

The ideal case is one where even though your code base is messy, you can easily see how you could achieve a clean code base through a series of short, discrete steps, where each step begins and ends with working code.

Kind of like how if you've got a string attached to something at the entrance of a cave, it doesn't matter much how deep in to the cave you get--all you have to do is follow your string back.

Of course I'm just a 19-year-old kid. Someone who's worked on a large software project should tell me if they like my theory or not.