

Startup Technical Debt - mattrepl
http://measuringmeasures.com/blog/2010/9/21/startup-technical-debt.html

======
kaib
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...](http://www.alphaitjournal.com/2009/06/cross-discovering-assets-and-
valuing.html)

------
gigantor
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.

~~~
hello_moto
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)?

~~~
gigantor
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.

------
astrofinch
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.

~~~
nitrogen
_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._

Your post would be just fine if you left that line off. It was well-stated,
agrees reasonably with my experience, and provides concrete points that can
easily be addressed by anyone who disagrees.

My next suggestion would be to try it yourself: join a large software project.

