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

11–20 of 114 posts

Re: The Way We Look at Technical Debt Is Wrong

#11

Post by jaggederest »

amelius wrote: post #8
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…

But often the choice is: do I implement this in an hour, or do I spend a week making a nice well-though-out framework for this, complete with test-suite (which may take multiple iterations to reach perfection). And you may pick the latter, but what if management wants to make a quick prototype and turn that into a product later? At that point you'll still be having the "technical debt" talk with your manager.

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.

That said, I'm not implying that you should slow down, just do the best possible work at all times. Don't do a crappy job just because you're time-limited - we all only have 24 hours a day, and there's always more work than can reasonably fit in. The moment you start going "I am going to lower my standards right now", you've started a trend.

I think it's interesting that people are always saying "hire the best possible people you can", and then saying "but don't ask them to do the best possible work they can do".

Re: The Way We Look at Technical Debt Is Wrong

#12

Post by ska »

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 reason to be hesitant about changing it, and instead it is worked around.

So this latter case behaves very much like "technical debt" . This system costs you engineering time every time you even think about touching it. It's hard to reason about, it's hard to change, and over time these problems get worse if you introduce workarounds in other parts of the system, because now they are worse and harder to work with.

This is a very real cost.

Re: The Way We Look at Technical Debt Is Wrong

#13

Post by dalke »

swalsh wrote: post #3

"Financial debt, however, accrues interest and hurts more regardless of what it is incurred for." I'd disagree, I think all technical debt accrues interest (similar to financial debt), but the interest rate is different. As the example about a usps api demonstrated, that has a near 0% interest rate. Of course if you were ever to need to update it (maybe usps updated its api) you'd get hit. A bad domain model has a hi…

A problem with comparing the metaphorical debt of technical debt to the financial one is that interest rates can be negative.

In addition, the term "debt" also applies to moral aspects, and not just financial ones. A builder may come back and improve something not because it's good for the employer or has financial benefits, but because of a belief that quality is good for the soul of the builder. That is also an aspect of technical debt.

Regarding the original article, it says tech companies are "successful because they got a product to market fast and at the right time". The "fast" is incorrect. Companies are successful if they are at the right time. If a company (like GO Corporation with pen-based computing) is fast but too early, they they are not successful. If a company (like Microsoft with Excel) is slow but eventually gets there, then they are successful.

"Fast" is therefore irrelevant in the face of "the right time." It can be that the right time is "as soon as possible", but that's not intrinsic to success.

Re: The Way We Look at Technical Debt Is Wrong

#14

Post by zdrummond »

Animats wrote: post #7

The article applies mostly to short-lived webcrap and appcrap, where time to market matters. There's software where reliability matters more than features - databases, for example. Source code repositories. Banking systems. Soon, automatic driving. (The coming "Internet of Crappy Things" is a real worry.)

Time to market always matters. If you created the most reliable and solid automatic car; one that never crashed or made any mistake, you would have an amazing product.

If you released it today, you would own the car market and you would be best pals with Elon.

If you released it in 50 years, people would think you are quaint for playing with that old-tech for a problem that been solved 10x over.

Re: The Way We Look at Technical Debt Is Wrong

#16

Post by samstokes »

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.

Re: The Way We Look at Technical Debt Is Wrong

#17

Post by qyv »

There are some things I agree with in this, however I think the context in which it is presented is flawed. This is particular: "Technical Debt is a Positive and Necessary Step in software engineering" is just incorrect. If technical debt was positive and necessary we would call it Technical Credit.

IMO a better context for this would be: real software engineering requires compromises. There are a number of competing factors that need to be juggled in order to be successful: time, money, complexity, quality, etc. The point should be that you need to balance these factors, not focus on one above all else.

Re: The Way We Look at Technical Debt Is Wrong

#18

Post by dccoolgai »

From years of experience, I detect in the tone of this piece a certain notion that product managers / non-technical people tend to form when working with developers - namely, that developers don't care about speed-to-market and would rather agonize and winge over perfect architecture and coding standards... What I think you'll find, more often than not, on the business end of this attitude is a developer(s) patiently trying to explain that speed-to-market is, in fact, directly related to the technical debt accrued on the project for all but the most static and inconsequential things. We must think and communicate about technical debt the way we do to keep errant PMs from drifting off into the Ice Cream Sea of Candyland where all of there half-thought-through ideas they demand be implemented immediately by cutting all corners have no impact on the next set of half-thought-through ideas they want implemented.

Re: The Way We Look at Technical Debt Is Wrong

#20

Post by [deleted] »

jaggederest wrote: post #11
amelius wrote: post #8

Earlier quoted context omitted.

But often the choice is: do I implement this in an hour, or do I spend a week making a nice well-though-out framework for this, complete with test-suite (which may take multiple iterations to reach perfection). And you may pick the latter, but what if management wants to make a quick prototype and turn that into a product later? At that point you'll still be having the "technical debt" talk with your manager.

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

[deleted]
Post reply on HN