Hacker News Reader

Comment by nostromo | Hacker News Reader

> what happens when you're too heavy on the "doing" end of the spectrum?

technical debt

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.

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!

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.

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

I believe the best solution right now may be to get an MVP without worrying about technical debt too much while not purposely doing things to step on your own feet while acknowledging you'll need to do a full rewrite before 1.0.

Technical debt is like real debt. In the grand scheme of things it's bad, but there are times when it makes sense to borrow from your future.

I used to think that way, then I realized that I should worry about building a product people will pay for before worrying too much about technical debt.

It's almost a Maserati problem when you think about it.

i think that is the right way to think on most software projects. But on projects that require rapid iteration and user testing(such as hit-based projects like games), technical debt could cause your iteration rate to be slowed to a crawl, and in the end you produce an inferior product.

Had the technical debt been paid up front, the iteration rate might have been much faster (e.g., good encapsulation and abstraction allows you to switch out things quickly to test different mechanics in a game), leading to a better end product that people will pay for.

Reply on news.ycombinator.com