Item — HN Reader

There's a discrepancy that the top comments here say that "some people can produce a ton of value by not caring about code quality" and "I didn't care about code quality and got bit later on". And people discuss that incurring technical debt with bad code can sometimes be worth it and sometimes not be worth it.

The logical implication of technical debt having an interest rate (i.e. It costs more to fix something later than now) is that like money, features have time value. This is what makes it worth it to incur technical debt.

Thinking about the implied interest rate of technical debt makes it easier to rank what should be prioritized for a fix. High interest debt should be paid off first. But you might also focus on refactors that reduce the interest rate, such as by modularizing your code so it's easier to replace down the line.

3 comments

Btw, if you like the financial metaphor, then technical debt is a bit of a misnomer. 'Technical debt' behaves a lot more like equity you sold than like debt you issued.

In the sense that the 'technical debt' is only something to worry about in the future, if your project goes anywhere. But if no-one ever uses your product, you don't need to fix the 'technical debt'.

Thank you! I like the metaphors because they allow me to think about related variables. What metrics would I use to compare different technical equity options? Is there an implied valuation of my project based on the % of developer time I have to spend fixing an issue related to the feature value?

I learned this lesson when working on very fast paced projects with way fewer developer resources than needed. to ship a feature on time, shortcuts in quality have to be made, but you learn to make the shortcuts in a way that are easier to go back and clean up later.

I became very fond of #TODO ‘s.

My manager gave me gruff the other day for adding a TODO that I had no intention of ever doing. TODOs are like a get out of jail free card. Don't want to do something the reviewer is likely going to call out? Just add a TODO.

That's why some people insists on having a name with each TODO, and some even want a name and a date.

some TODOs are actually WOULDDOs

I still find them helpful when the change is outside the cope of the current task. I especially like the ones that include both a reference to a Jira ticket (or similar), and an explanation of why, or any gotchas:

    # TODO: (CAFE-1256) Refactor steamed-liquid stuff to support non-dairy options
    #     We don't currently support non-dairy coffee additives, but once we do 
    #     we will need to ensure that the steamed-liquid transport 
    #     also alerts when users have a dairy allergy.

This is a lot of stuff to add for some things, so we might not want it everywhere, but it helps explain to a reader why we don't currently have it built (product doesn't need X yet), but also has hooks to existing (planned/canceled) tickets and is easily greppable (e.g. "non-dairy" or ticket name).

I agree with this analysis. Another important factor is: How likely will this code actually be used and drive business value?

If very likely, then you should invest in making the code high-quality. If unlikely, then you should half-ass the code strategically

I've declared quality bankruptcy. Decisions are now driven by user needs. Did I half-ass that feature? Yes. Is anyone actually using it despite crying it's essential? No. Then it's not getting cleaned up. Are they not using it because it's shoddy? I guess we'll never know.