Ask HN: What's your definition of a technical debt? | Hacker News Reader

Ask HN: What's your definition of a technical debt?

11 pointsjoddystreet8 comments

What are your parameters or mindset or mental model to figure out a technical debt?

How do you deal with the tech debt? How do you prioritize the tech debt severity?

In general, not restricted only to the computer science field, how is the technical debt described for a particular field?

To me, field: computer science - software, any denormalized database object is technical debt, with a severity directly proportional to the amount of additional code being written to manage denormalization.

View on HN

Tech debt is something that saves time/resources now, at the cost of even more time/resources later.

This could include not writing tests, spaghetti code, poorly planned or poorly defined features, and so on.

I treat it much like financial debt. The best ones are the ones you might not have to pay off - experimental features that may not be used or that could be replaced.

There are some cases where the amount you save vs future cost is really poor, e.g. denormalized database or spaghetti architecture. It's quite a senior/specialist skill to get the right balance.

Technical debt is debt. It provides leverage but accrues interest. Technical debt is wiped away in bankruptcy.

The last is important. Technical debt accrued in pursuit of a bad idea goes away when the project is abandoned. For a startup that is scaling rapidly, technical debt goes away because the problems of scale require rewriting even the best tuned small scale code.

Even in ordinary business cases, the cost of carrying technical debt is very often lower than the cost of eliminating it. One extra engineer to deal with it, is less expensive and lower risk than rewriting the code base on moral grounds. Carrying it contributes more to the bottom line and cash flow than an effort to eliminate it.

Field: software development

A technical debt is anything that slows down either performance and development.

It could be:

- memory leaks

- zombie routines

- variable/function/type/endpoints misnomer

- out of date comments

- unhandled errors

- technological goldplates

- readability-hindering and overly-strict conventions

- non-forward compatibility

- unnecessary side effects / mutability

- god objects

- improper architecture

- unclear separation of concern

- flow dead-ends

- non-scalable storage access strategy

- unused data created in memory (seriously, this is annoying. Imagine reading codes like these like this:

fn renderSomeHeavyStuff(errorKind: string) {

  let renderables = {

    "kindA": someHeavyProcedureA(),
    "kindB": someHeavyProcedureB(),
    "kindC": someHeavyProcedureC(),

  }

  return renderables[errorKind]

}

)

- structure written imperatively

- stories written declaratively

- premature abstraction

- leaky abstraction

- overprotective abstraction

- over-complex resource endpoint

- under-complex procedure endpoint

IMO there are two types of tech debt.

The first is "techincal" debt - which is stuff that gets ignored for the sake of faster delivery but slows down development in the long run. Missing tests, spaghetti code, weird hacks, poor documentation.

The second type is "product techincal" debt - stuff that purposely half baked / half delivered for the sake of meeting deadlines. Features that are delivered or bugs that are fixed in less-than optimal ways.

I'm much more sympathetic to the second kind. At a certain point you always have to negotiate quality with speed. As long as there is a shared understanding that "this isn't perfect, but we're agreeing to move forward", it can generally be corrected eventually.

The first kind is usually the kind that gets piled up though. It's the stuff that causes engineers to want to burn down everything and rebuild, and eventually leads people to quit. Nothing is worse than being forced under time constraints and then realizing you can't implement a new feature without being forced into a major refactor, or spending a week on adding tests that should have been there in the first place. It's this stuff that causes the most stress IMO, because management usually sees it as unnecessary.

Basically, when I look at something and think "ugh". Code which is usually much too long for what it's doing, is hard to follow, or will otherwise likely limit our team's ability to change the product in the future.

Due to our small team size and low test coverage, we will almost always leave such code alone until such time that we have the chance to work on the product in earnest (e.g. changing or adding a feature that touches the affected code in some way).

Search for TODO, HACK, etc in the code base to uncover the obvious technical debt.

The hidden ones are those undocumented code, workaround, config settings etc that no one understands what it does.

Code that has not been reviewed. Worse is code that has not been documented. Code without proper test suite. Code without code management.

> technical debt

https://vimeo.com/108441214

Reply on news.ycombinator.com