
Ask HN: What's your definition of a technical debt? - joddystreet
What are your parameters or mindset or mental model to figure out a technical debt?<p>How do you deal with the tech debt? How do you prioritize the tech debt severity?<p>In general, not restricted only to the computer science field, how is the technical debt described for a particular field?<p>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.
======
muzani
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.

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

------
valand
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

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

------
trilinearnz
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).

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

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

------
ooooak
> technical debt

[https://vimeo.com/108441214](https://vimeo.com/108441214)

