Musings on Tech Debt (2020) • Hacker News Board

Re: Musings on Tech Debt (2020)

#11

Post by foohoo_blue » Sun, Jul 04, 2021, 12:55 PM UTC

PaulHoule wrote: post #8

foohoo_blue wrote: post #7

Earlier quoted context omitted.

My opinion is that 'not thinking or understanding' the work shouldn't be labelled as technical debt. Technical debt should be a conscious decision about an implementation that needs to be revisited in the future, either for scalability, readability, extendibility etc concerns. Also, in that vein, not writing unit tests should not be considered technical debt, that is part of any implementation and should be factored…

If it is ‘debt’ you actually plan to pay it. Sometimes I’ve put off writing the unit test (in an area of the code that has been around for months or years w/ little or no testing.) and made a bug fix or small feature. I had a plan to revisit it when coming back to the same zone and did. I’ll justify it like this. If a system is not well-modularized for testing and there isn’t a precedent for mocking or similar method…

"If it is ‘debt’ you actually plan to pay it."

Exactly that, and it should be a decision to accrue it.

Re: Musings on Tech Debt (2020)

#12

Post by wirthjason » Sun, Jul 04, 2021, 1:26 PM UTC

Metaphors hide and highlight. Sure there’s things “tech debt” doesn’t cover but there’s a lot that it does, it doesn’t mean it’s wrong.

One area is when a developer can deliver something to the business quickly by amassing large amounts of debt. The developer gets patted on the back, maybe a raise or a promotion, then leaves. That debt is then paid off by future generations.

Tech debt doesn’t necessarily means the design doesn’t work. The design could be functional for the business needs at the time developer but hard to change when future requirements are needed. Poor variable names, spaghetti code, hard coded values, etc. are often “cosmetic”. Fixing that stuff doesn’t really change the overall design but the rewards pay dividends when a new developer needs to understand and update the system.

Re: Musings on Tech Debt (2020)

#13

Post by [deleted] » Sun, Jul 04, 2021, 1:30 PM UTC

[deleted]

Re: Musings on Tech Debt (2020)

#14

Post by akitzmiller » Sun, Jul 04, 2021, 1:52 PM UTC

>> Tech debt, unlike financial debt, is an asset to no one, it’s only a diminishment of value.

A lot of the technical debt discussions I've read are very development team focused. What is often missing is the value to the user. Assuming your software is meant to make some group of users more efficient, over certain time periods, the user is getting value regardless of the cleanness of the code (within certain reasonable limits).

For most of my career, I've done small team internal software projects. The value of those projects is the improved efficiency of the users minus the amount of developer hours put in. Time spent refactoring can absolutely be worthwhile, but code improvements that don't add to user efficiency have to be carefully chosen, otherwise you're cutting into the value the organization is accumulating.

Re: Musings on Tech Debt (2020)

#15

Post by analog31 » Sun, Jul 04, 2021, 2:28 PM UTC

akitzmiller wrote: post #14

>> Tech debt, unlike financial debt, is an asset to no one, it’s only a diminishment of value. A lot of the technical debt discussions I've read are very development team focused. What is often missing is the value to the user. Assuming your software is meant to make some group of users more efficient, over certain time periods, the user is getting value regardless of the cleanness of the code (within certain reasona…

Oddly enough, tech debt is an asset to the people who are paid to maintain it.

Re: Musings on Tech Debt (2020)

#16

Post by akitzmiller » Sun, Jul 04, 2021, 2:38 PM UTC

analog31 wrote: post #15

akitzmiller wrote: post #14

>> Tech debt, unlike financial debt, is an asset to no one, it’s only a diminishment of value. A lot of the technical debt discussions I've read are very development team focused. What is often missing is the value to the user. Assuming your software is meant to make some group of users more efficient, over certain time periods, the user is getting value regardless of the cleanness of the code (within certain reasona…

Oddly enough, tech debt is an asset to the people who are paid to maintain it.

Putting two kids through college on it.

Re: Musings on Tech Debt (2020)

#17

Post by jpswade » Sun, Jul 04, 2021, 2:49 PM UTC

I rarely think tech debt is actually technical debt, that would imply it’s totally down to a technical decision when most of the time we make technical decisions based on real business requirements that were appropriate at that time.

For example, as a business why would you make an application with perfect and ideal code before proving that there’s a market for it. It’s akin premature optimisation.

I also think it’s a poor choice of wording because debt has negative connotations and instead should really be thought of as a business decision, that once the product starts to mature, the mortgage will need to be paid off.

If it was truly a debt, then surely for it to be financially viable there would need to be an equal credit somewhere, however this is never mentioned.

It’s more like picking the right tool for the job at the right scale.

If you want to dig a hole in your garden a normal spade will do just fine, if you want to dig foundations for a building, you might need something a bit more. You can still use a spade or many spades or perhaps you can pay for a digger. It’s a trade off.