Hacker News new | ask | show | jobs
by geocar 1786 days ago
> "Technical debt is the burden that implementation choices may place on future development."

> With regard to its coherence, I say that it is empirically verified: it actually happens!

Something happens, on this we can agree, but if you are making checkers and find out you need chess, it isn't that making chess is any harder than it was before you did anything -- so no, I would not agree that it placed any burden on future development.

No, I think the real issue is that you have already paid for checkers and so you feel unhappy that your time (and maybe money) was wasted on checkers when you simply can't sell checkers because all along you needed chess.

> The mere fact that most of the technical things we choose to do are done for non-technical reasons is enough to establish that. The root cause of a problem and its broad consequences are separable concerns.

The root cause is that you do not know what you want. Writing the crappiest version of checkers as quickly as possible is a great way to find out it is the wrong thing. Trying to write an "abstract board game" instead of just writing checkers so that the decision to choose checkers or chess could be delayed as long as possible is not: It assumes that it is mere time that informs us of what we want, rather than the feedback of seeing what we don't want.

> it is completely reasonable to consider the situation where, say, I give a farmer cash in return for some produce at harvest time to be a debt

We can fantasize about a great many things, including this, but software is not produce that is harvested and sold; you do not plant great software seeds to grow into great software trees. No, the debt is the cash that the farmer received, just like the debt is the cash you receive to write the software. The software itself is not debt and never was.

1 comments

not all "technical debt" is wanting chess when we built checkers.

it can just be building a minimal chess quickly using methods/frameworks that are not easily extensible to future requirements related to chess.

the vast majority of software projects will have features/requirements that evolve after the initial design, it is a rabbit hole to try and guess all of those, but some things are just common sense but would add a little time to the first milestone. then you are in the position of tacking on things indefinitely making it a horrible tangled mess.

> it can just be building a minimal chess quickly using methods/frameworks that are not easily extensible to future requirements related to chess.

You should not build something you do not need if you know it is wrong and you will not need it.

That is just wrong.

Many engineering managers do this to “show progress” but this is because they are bad at their job.

On the other hand, if you need it so the UI team has a mock to work against (so that they can explore what interfaces they really need), it isn’t debt at all.

Technical debt doesn't even need to be related to future requirements. It could be building something that's only mostly right to get something out faster.