Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Way We Look at Technical Debt Is Wrong

bigeng.io

Post reply on HN
Print view View original

31–40 of 114 posts

Re: The Way We Look at Technical Debt Is Wrong

#31

Post by d23 »

jaggederest wrote: post #5

I don't believe that, even in the short run, taking shortcuts actually saves you time. It's much like working 12 hour days - you feel more productive, but you're not actually getting any more done on a larger scale. There's an obsession with 'hurry up and get it done' that contributes little on a larger scale. I also don't believe it's possible to pick the 'important' areas of code a priori and make only those areas…

> I think that quality is something you can't 'bolt on' later. It has to be built in, top to bottom, throughout your organization, code base, and personal skills.

I agree with all of your points and just wanted to add one more thing that doesn't seem to be addressed much. The author mentioned technical debt didn't have an "interest rate", but it absolutely does. As soon as you start to add debt to a particular part of the code base, it must be paid back immediately the next time you or someone else has to work on that same section. This may genuinely not matter for a one-off script, but if it's code that will ever be worked on again it can start a snowball effect that causes the interest to compound and usually manifests itself as code that's buggy, unstable, and hard to work on.

Re: The Way We Look at Technical Debt Is Wrong

#32

Post by ekidd »

I'm unconvinced that accepting large amounts of technical debt allows startups to react faster.

I've definitely seen startups that have almost found a good idea, but can't tweak it, scale it, or make it stable, because they're overwhelmed by technical debt and even simple changes have become engineering death marches.

Letting your back-end code turn into a complicated, disgusting mess means that adding critical features may become a multi-week nightmare. Which is then followed by a series of additional multi-week nightmares for each successive feature.

Now, this isn't to say that obsessive code-polishing is a good idea, either. But startups require rapid iteration, and you can't iterate especially rapidly when your code is complicated, badly organized, and poorly tested.

Re: The Way We Look at Technical Debt Is Wrong

#33

Post by wcummings »

>For instance, if you’re using a relational database, and your models are improperly structured, this will cause you significant pain later on. If you build a system using NoSQL that later needs to become highly relational, you will incur massive frustration in the future.

I don't think this is what Linus was talking about...

Re: The Way We Look at Technical Debt Is Wrong

#35

Post by ska »

samstokes wrote: post #16
ska wrote: post #12

The author seemingly misses an important way in which this can be looked at as "real". Some subsystems don't change much because they already do what is needed and aren't broken. Sure, the code could be improved, but it's not important enough to do (or at least, to do now). Other subsystems don't change much because they are scary to change. If the system is brittle and poorly designed, engineers may have very good r…

This is a good point, but I think it's very much in line with what the OP is saying. Technical debt hampers your ability to change . Anything you're scared of changing clearly fits that description. Those workarounds that get created instead of changing the scary thing put me in mind of the "scar tissue" metaphor that SapphireSun proposed elsewhere in this thread.

I'm not disagreeing with the main thrust of the OP's argument, but with the statement that "Technical Debt isn't real".

I think that it often is best thought of as "real debt" in that it costs you time and attention, and (at least some of the time) that cost compounds over time. In other words, some of your engineering spend is just going to service this debt, not produce anything useful. That's a very real opportunity cost.

Re: The Way We Look at Technical Debt Is Wrong

#36

Post by jaggederest »

amelius wrote: post #22
jaggederest wrote: post #11

Earlier quoted context omitted.

I think that's a straw man argument - the choice isn't between an hour and a week, it's a choice between an hour and two or three hours. I don't think that making a framework for every change is a good idea, but I do think that, if you've only got an hour to work on something, you'd better make some quality tests for it, because under time pressure you're even more likely to make the sorts of errors that tests catch.…

But a good programmer always sees a number of solutions to a particular problem. Let's say he sees 10 solutions. Solution 1 costs an hour to implement, but gives crappy code and he knows it. Solution 9 gives good quality code, but takes a week to implement, and he then has to sell this to his boss. And then there's solution number 10, which requires the programmer to invent a new programming language, and requires at…

I think what you hear me saying is "never do anything less than perfect work". I'm saying "given your current constraints, don't choose a worse option when a better one is available". Those constraints include time, your skills and beliefs, the environment you work in, the project you're working on, and the problem you're trying to solve.

Re: The Way We Look at Technical Debt Is Wrong

#38

Post by mrisse »

jaggederest wrote: post #5

I don't believe that, even in the short run, taking shortcuts actually saves you time. It's much like working 12 hour days - you feel more productive, but you're not actually getting any more done on a larger scale. There's an obsession with 'hurry up and get it done' that contributes little on a larger scale. I also don't believe it's possible to pick the 'important' areas of code a priori and make only those areas…

It strikes me as a little absurd to say that taking shortcuts is always a bad idea. Let's look at a few shortcuts you might take.

Allow the page to break if the user's browser does not support websockets If you know that 95% of your target audience uses modern browsers this seems like a reasonable compromise.

Don't write enough unit tests Maybe you're using a library that is difficult to mock. Maybe most of your logic is happening at the db layer. Eventually you may want to thoroughly test this piece of code, but it's a ton of work to mock a database in a meaningful way.

Write a monolithic service instead of a modular one While it's bad to let a single service grow too large, when you're starting out, it can be helpful to write it all out, and _then_ see how it can be broken apart. (It's often hard to foresee everything at the design stage.)

Finally, a lot of code ends up being never used. Nobody cares about well-factored well-tested code that isn't used. Sometimes a dirty version is the quickest way to tell if a project makes sense at all.

Re: The Way We Look at Technical Debt Is Wrong

#39

Post by crdoconnor »

amelius wrote: post #22
jaggederest wrote: post #11

Earlier quoted context omitted.

I think that's a straw man argument - the choice isn't between an hour and a week, it's a choice between an hour and two or three hours. I don't think that making a framework for every change is a good idea, but I do think that, if you've only got an hour to work on something, you'd better make some quality tests for it, because under time pressure you're even more likely to make the sorts of errors that tests catch.…

But a good programmer always sees a number of solutions to a particular problem. Let's say he sees 10 solutions. Solution 1 costs an hour to implement, but gives crappy code and he knows it. Solution 9 gives good quality code, but takes a week to implement, and he then has to sell this to his boss. And then there's solution number 10, which requires the programmer to invent a new programming language, and requires at…

>But a good programmer always sees a number of solutions to a particular problem. Let's say he sees 10 solutions. Solution 1 costs an hour to implement, but gives crappy code and he knows it. Solution 9 gives good quality code, but takes a week to implement, and he then has to sell this to his boss.

A good programmer will try and improve code the code incrementally, and won't bother trying to sell anything.

Re: The Way We Look at Technical Debt Is Wrong

#40

Post by cunac »

amelius wrote: post #22
jaggederest wrote: post #11

Earlier quoted context omitted.

I think that's a straw man argument - the choice isn't between an hour and a week, it's a choice between an hour and two or three hours. I don't think that making a framework for every change is a good idea, but I do think that, if you've only got an hour to work on something, you'd better make some quality tests for it, because under time pressure you're even more likely to make the sorts of errors that tests catch.…

But a good programmer always sees a number of solutions to a particular problem. Let's say he sees 10 solutions. Solution 1 costs an hour to implement, but gives crappy code and he knows it. Solution 9 gives good quality code, but takes a week to implement, and he then has to sell this to his boss. And then there's solution number 10, which requires the programmer to invent a new programming language, and requires at…

I am sure that most developers want to deliver working code of reasonable quality (most likely not hacks)

I am sure that most product/project managers want feature as soon as they can think of it

Post reply on HN