[HN Gopher] Kinds of Technical Debt
___________________________________________________________________
Kinds of Technical Debt
Author : nichochar
Score : 39 points
Date : 2021-07-11 16:16 UTC (6 hours ago)
(HTM) web link (bytesizetheories.com)
(TXT) w3m dump (bytesizetheories.com)
| bobbydreamer wrote:
| Now a days forceful version migration can also be considered a
| technical debt
| MaxBarraclough wrote:
| > tech debt is not always bad. Using MongoDB to prototype ideas
| or writing an ugly function that does abusive things to solve a
| critical bug can be justified, and the optimal way to do things.
| It's just a matter of doing so deliberately.
|
| I've seen this put slightly differently before: technical debt is
| like financial debt. Drowning in it is obviously bad, but it has
| its place, and it's typically unwise to aim to never take on
| debt.
| RangerScience wrote:
| Ehh. There are two kinds of tech debt:
|
| * Things you haven't built yet
|
| * Things you shouldn't have built that way
|
| IMO first one is OK, and the second one is what kills you.
|
| OP is absolutely correct to point out you can find tech debt in
| code, architecture and data, but... That doesn't really help to
| make general decisions about it, both in handling it once you
| have it, and in making decisions about accumulating it.
| Msurrow wrote:
| I agree with your model, but I also find Fowler's model on tech
| debt helpful:
| https://martinfowler.com/bliki/TechnicalDebtQuadrant.html
|
| It's sort of one level "deeper" that the one you use. For me it
| is helpful because it allows to work with temporality in
| decisions on tech debt, ie "do we have time to do this right or
| do we need to get sh*it done now and pay later". This is
| valuable because it allows you to work with tradeoffs in
| architecture and design.
|
| Tradeoffs are inevitable in SW design and sometimes some thing
| is gonna be more important that not taking on tech debt [right
| now]. The important thing is to remember that debt has to be
| payed off.
| RangerScience wrote:
| Bonus: This model also works on all kinds of non-financial
| debt!
|
| * Things you haven't dealt with.
|
| * Things you shouldn't have dealt with that way.
|
| Try looking at your "emotional debt" (what you go to a talk
| therapist to talk about) with under this frame, it's pretty
| handy.
| mathewsanders wrote:
| I found this list really useful and will be sharing with my team.
| Thank you author and OP!
|
| In my mind I've always categorized tech debt as being broader,
| and including pretty much anything that doesn't have a direct
| benefit to our end users. So this can include things like moving
| our repos from Bitbucket to GitHub, updating a dependency that
| has a breaking change (e.g. migrating from one version of
| Bootstrap to another) or even something more significant like
| changing from a legacy authentication model to something more
| modern like OIDC. But I wonder if with this mental model I've
| taken it too far.
| aliasEli wrote:
| One of the big problems with "modern development projects" is
| that they start coding from day 1. The first step in any good
| project should be to learn as much as possible about the
| requirements before making serious decision about its
| architecture. Designing a model of the data (even if it is only a
| very rough one) is usually very helpful in the first phase of a
| project.
|
| It is still true that mistakes that are made during early phases
| of the project are much harder to fix than recent mistakes.
| Zababa wrote:
| I've often heard that the best way to learn about customers is
| to put a product in front of them and see how they react.
| People have a hard time knowing what exactly they want in a
| vacuum, but once you give them something to play with, they're
| usually good at saying what's good and what's not.
___________________________________________________________________
(page generated 2021-07-11 23:02 UTC)