3 ms·

I'll add to that... Technical Debt = When you coded without thinking AND your project is successful and growing. It's debt because now you have to go back and

I'll add to that... Technical Debt = When you coded without thinking AND your project is successful and growing. It's debt because now you have to go back and fix/change the code. Technical Grant = When you coded without thinking BUT your project is NOT successful and fails. It's a grant because it saved you time. Most projects / startups fail so for most people "Just Do It" works better. Plus the product you envision is almost never the product you end up with. So all that thinking you invested can be a waste of time.

rjzzleep 13y ago
And I'll add to that, you better pay off your technical debt otherwise you might end up with problems, in the long term - seen it way too many times. http://www.codinghorror.com/blog/2009/02/paying-down-your-technical-debt.html http://www.codinghorror.com/blog/2009/02/paying-down-your-te...
tfb 13y ago
It almost sounds to me like if the product we end up with isn't what was envisioned, then it wasn't executed properly. I'm not saying that's a bad thing, since how it ends up is usually due to the market guiding the product's development; and if the market is holding your hand, you're probably making some money, which is the goal of most startups. But I would bet that if you let the market dictate too much too soon, it will be harder to truly innovate, which is usually what the original vision was about. I'm obviously making some pretty big assumptions here but people know only what they know, and sometimes it takes carefully timed and constructed execution to snap them out of it to create a new paradigm and take things to the next level.
thrush 13y ago
Have you ever heard of the concept of Technical Investment? Sometimes one's skill level simply makes it really difficult to avoid technical debt, but as you gain experience, your skill level rises and your code begins to minimize debt more and more. Rather than spend your time refactoring, if you spend that same time improving your skill then the loss of debt in the future may outweigh the debt you've already accumulated at each step. Improving skills can take the form of learning a new tool (css -> sass), a new programming pattern (like currying and monoids in functional programming), and more along those lines. Granted, a huge problem with technical debt comes when your playing with a team, and if X people are going to be using your code, but it takes Y time to explain how that code works, then if takes Z time to refactor that code, and only W time to explain after the refactoring. Then, if XY > Z + XW, refactor every time!

rjzzleep 13y ago

And I'll add to that, you better pay off your technical debt otherwise you might end up with problems, in the long term - seen it way too many times. http://www.codinghorror.com/blog/2009/02/paying-down-your-technical-debt.html http://www.codinghorror.com/blog/2009/02/paying-down-your-te...

tfb 13y ago

It almost sounds to me like if the product we end up with isn't what was envisioned, then it wasn't executed properly. I'm not saying that's a bad thing, since how it ends up is usually due to the market guiding the product's development; and if the market is holding your hand, you're probably making some money, which is the goal of most startups. But I would bet that if you let the market dictate too much too soon, it will be harder to truly innovate, which is usually what the original vision was about. I'm obviously making some pretty big assumptions here but people know only what they know, and sometimes it takes carefully timed and constructed execution to snap them out of it to create a new paradigm and take things to the next level.

thrush 13y ago

Have you ever heard of the concept of Technical Investment? Sometimes one's skill level simply makes it really difficult to avoid technical debt, but as you gain experience, your skill level rises and your code begins to minimize debt more and more. Rather than spend your time refactoring, if you spend that same time improving your skill then the loss of debt in the future may outweigh the debt you've already accumulated at each step. Improving skills can take the form of learning a new tool (css -> sass), a new programming pattern (like currying and monoids in functional programming), and more along those lines. Granted, a huge problem with technical debt comes when your playing with a team, and if X people are going to be using your code, but it takes Y time to explain how that code works, then if takes Z time to refactor that code, and only W time to explain after the refactoring. Then, if XY > Z + XW, refactor every time!