3 ms·

Technical Debt and the Lean Startup

16 points by DanielRibeiro 15y ago

DanielBMarkham 15y ago
Technical debt is the latent cost of fixing quality problems you incur because you cut corners. Instead of the "cost" of the debt staying the same, it actually grows over time. The longer you leave your technical debt, the bigger pain it will be to fix. But there's an underlying assumption: technical debt cannot have any value at all unless the code itself has value. In a business setting, you code something, the Product Owner approves it, it starts making money for the business. It has value. In a startup scenario, the code you write only has about a 5% chance of ever being worth anything at all. Whether or not you want to be a craftsman or a businessman is left as an exercise to the reader. But my advice is always do the math. There's a lot of solid code out there that isn't worth jack shit -- and a lot of proud programmers who will tell you how awesome their code is. 100% of 0 is still 0. As a side note, I'm always amazed at the stories of technical debt where a team hacks something butt-ugly, then gets a million users, then the whole thing is a piece of shit. When practitioners talk about this, it's almost like the moral is how bad hacking and bad coding is. They completely miss the point that getting the million users here is the significant event, not the coding style. You get a million users, you can complain about all kinds of things. Trust me. You'll work it out. Let some other guy write the book about what fools you were. You have the million customers. He doesn't. Note that I'm not saying to code like crap. I'm just saying that everything you do in a startup -- programming, marketing, sales, accounting, etc -- has to be measured in terms of gaining and keeping customers. You have to do the math for your particular situation and figure out where the trade-off is (insert long discussion about how important MVP is here) Pragmatism always. Thinking in absolutes will kill you every time.
- r00fus 15y ago
  Like some might say: "it's a nice problem to have"... some of us are working night an day towards a happy future dilemma of paying technical debt against a valuable product
- DanielRibeiro 15y ago
  Completely agree. Even Kent Beck, the author of Extreme Programming, discussed this on his Flight of a Startup[1] [1] http://www.threeriversinstitute.org/blog/?p=251 http://www.threeriversinstitute.org/blog/?p=251

16 points by DanielRibeiro 15y ago

Technical debt is the latent cost of fixing quality problems you incur because you cut corners. Instead of the "cost" of the debt staying the same, it actually grows over time. The longer you leave your technical debt, the bigger pain it will be to fix. But there's an underlying assumption: technical debt cannot have any value at all unless the code itself has value. In a business setting, you code something, the Product Owner approves it, it starts making money for the business. It has value. In a startup scenario, the code you write only has about a 5% chance of ever being worth anything at all. Whether or not you want to be a craftsman or a businessman is left as an exercise to the reader. But my advice is always do the math. There's a lot of solid code out there that isn't worth jack shit -- and a lot of proud programmers who will tell you how awesome their code is. 100% of 0 is still 0. As a side note, I'm always amazed at the stories of technical debt where a team hacks something butt-ugly, then gets a million users, then the whole thing is a piece of shit. When practitioners talk about this, it's almost like the moral is how bad hacking and bad coding is. They completely miss the point that getting the million users here is the significant event, not the coding style. You get a million users, you can complain about all kinds of things. Trust me. You'll work it out. Let some other guy write the book about what fools you were. You have the million customers. He doesn't. Note that I'm not saying to code like crap. I'm just saying that everything you do in a startup -- programming, marketing, sales, accounting, etc -- has to be measured in terms of gaining and keeping customers. You have to do the math for your particular situation and figure out where the trade-off is (insert long discussion about how important MVP is here) Pragmatism always. Thinking in absolutes will kill you every time.

r00fus 15y ago
Like some might say: "it's a nice problem to have"... some of us are working night an day towards a happy future dilemma of paying technical debt against a valuable product
DanielRibeiro 15y ago
Completely agree. Even Kent Beck, the author of Extreme Programming, discussed this on his Flight of a Startup[1] [1] http://www.threeriversinstitute.org/blog/?p=251 http://www.threeriversinstitute.org/blog/?p=251