3 ms·

Essentially a technical debt is an unvalidated assumption that other unvalidated assumptions are worth pursuing. A hunch about hunches of sorts. The article is

Essentially a technical debt is an unvalidated assumption that other unvalidated assumptions are worth pursuing. A hunch about hunches of sorts. The article is full of them describing every way to think about technical debt. And it's practically impossible to neither prove nor disprove the claims of technical debt without a lot of work, making it super easy to justify anything with technical debt. Naturally it becomes a term of authority and power to sneak in things unlikely to produce anything of value. Could be a sign that things got too toxic in software development if developers can't even talk openly about experimentation and research.

sonnyblarney 8y ago
Technical debt concerns are not necessarily 'unvalidated' - at least not to the extent that almost everything is a little fuzzy in tech anyhow. For example: you started a few feature with a few scripts, added a few new things here and there ad-hoc. Now it's growing and full blown and nary impossible to maintain. A more clear understanding of the problem space now exists, and also that a refactor would make sense. The continued inability to really move forward due to the rag-tag system is a kind of debt, and the trade off/decision has to be made as to wether or not the team needs to take a few steps back before moving forward. This is really common. I worked at BlackBerry during their heyday. If you are old enough to remember, there used to be international headlines when the BB email service went down. Everyone in the press was using BB and would harp on it. This is partly because BlackBerry had made a bunch of acquisitions and gun-taped the systems together, as opposed to properly integrating them. There was a real 'cost' to this bad press. The only real and fundamental way to avoid those systematic failures was to do a proper integration which in and of itself was a risky and unwieldy proposition for the company at the time. I'd argue that was a fairly material and validated form of technical debt.

sonnyblarney 8y ago

Technical debt concerns are not necessarily 'unvalidated' - at least not to the extent that almost everything is a little fuzzy in tech anyhow. For example: you started a few feature with a few scripts, added a few new things here and there ad-hoc. Now it's growing and full blown and nary impossible to maintain. A more clear understanding of the problem space now exists, and also that a refactor would make sense. The continued inability to really move forward due to the rag-tag system is a kind of debt, and the trade off/decision has to be made as to wether or not the team needs to take a few steps back before moving forward. This is really common. I worked at BlackBerry during their heyday. If you are old enough to remember, there used to be international headlines when the BB email service went down. Everyone in the press was using BB and would harp on it. This is partly because BlackBerry had made a bunch of acquisitions and gun-taped the systems together, as opposed to properly integrating them. There was a real 'cost' to this bad press. The only real and fundamental way to avoid those systematic failures was to do a proper integration which in and of itself was a risky and unwieldy proposition for the company at the time. I'd argue that was a fairly material and validated form of technical debt.