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.
What about Netscape? They did a re-write after their product reached a critical mass no? Or maybe I'm wrong (hence, Netscape is not THE most sought after product)?
Netscape was certainly what Joel Spolsky was referring to in terms of never rewriting software (http://www.joelonsoftware.com/articles/fog0000000069.html). They dominated the browser wars in the early days since they released their browser much earlier than IE, with the added cost of technical debt. I'm not sure what ultimately caused their downfall, but I suspect it wasn't due to their codebase, but rather an inability to figure out how to properly monetize their large userbase.
Comments
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.
What about Netscape? They did a re-write after their product reached a critical mass no? Or maybe I'm wrong (hence, Netscape is not THE most sought after product)?
Netscape was certainly what Joel Spolsky was referring to in terms of never rewriting software (http://www.joelonsoftware.com/articles/fog0000000069.html). They dominated the browser wars in the early days since they released their browser much earlier than IE, with the added cost of technical debt. I'm not sure what ultimately caused their downfall, but I suspect it wasn't due to their codebase, but rather an inability to figure out how to properly monetize their large userbase.