Comment by AndrewKemendo | Hacker News Reader

Comment by AndrewKemendo | Hacker News Reader

Parent Full thread

>I'd posit that technical debt gets created because of time pressure, and that it stays because of continued time pressure

I think you could boil everything down to "time pressure" and not have any good insights on a problem. For us our technical debt came in the form of resource constraints, namely not having enough money to hire someone to be able to do a task in the most optimal way. Sure we didn't have years and years to learn a new codebase but I don't consider that "time pressure" in the same sense.

I do think in general though if you are "hacking" on a product, you are almost by definition not building it in the most optimal way. In general things are left out or overly complex, whether it be documentation or streamlined code or building with a non-native SDK instead of native development technical debt sneaks in there.

Or how about developer maturity? Looking back at some of the projects I worked on when I was just starting out as a professional developer, I can tell you without a doubt that I introduced technical debt. It wasn't because of time pressures, I had plenty of time, it was simply because I was so green that I didn't know any better.

For example, I built a distributed video transcoding system a few years back, and for the use case at the time it worked great. But let's say people want a new video format? That's a large rewrite. Want to add more servers into the worker pool? That's a large rewrite (the code was written to assume a 1:1 ratio of certain servers, which was dumb).

Basically anything that you might want to change was made harder by the code that I wrote to get the job done initially. Over the years you start to recognize that, and write your code a little smarter and more change tolerant (hopefully introducing less technical debt).

Agreed, though I would distinguish tech "debt" from using your same tool to solve different problems. In general I would view tech debt as something that you know you are incurring eg. this situation: I know that this hack I am doing is going to need to be fixed later to implement Y, but since we need to implement X right now we have to just get it done

Yeah, my point wasn't that you can't drive deeper into the problem and come up with something more specific, but that the statement this article leads with (''Most people assume technical debt is there because of time constraints') is misleading. Of course people assume that, because most of the time it's true.

Reply on news.ycombinator.com