Three Kinds of Good Tech Debt

Post by TheLastPass » Tue, Aug 13, 2019, 7:45 PM UTC

davnicwil wrote: post #59

The article links tech debt to financial debt early on, and this is exactly what the analogy is - it is best to be as literal as possible about it. What is good debt? It's taking money from someone, promising to pay them back more money in the future, and using the original money to make even more money than that , so both you and the lender profit. Good tech debt is just the same. It's taking shortcuts now to save t…

Post by rickbad68 » Tue, Aug 13, 2019, 7:46 PM UTC

theturtletalks wrote: post #89

jboy55 wrote: post #88

Tech Debt, to me, grows with every line of code you write that didn't replace a line of code. Consider how many projects start with the idea, 'I'll rewrite this and get rid of the tech debt'. First, If the original code isn't deleted, you've added to the tech debt. Now every new engineer will need to learn two chunks of code, and every existing engineer will need to support both. Second, unless you've had a major epi…

If tech debt is inevitable, what’s the solution? Good internal documentation and rewrites every few years?

Post by aeorgnoieang » Tue, Aug 13, 2019, 7:48 PM UTC

Gibbon1 wrote: post #70

WorldMaker wrote: post #61

Earlier quoted context omitted.

I like to point out as well that it isn't tech "debt" if there's no "IOU". For instance, in the hard-coding example, it's conventional wisdom to avoid hard-coded magic constants for a few reasons including it sometimes is hard to figure out later why a magic constant was used, and in an if/else branch situation like that maybe tough to figure out when you can cleanly refactor those branches. If the case is well docum…

I have a good example of no IOU. Friend 20 years ago worked on a content streaming platform. They needed a dispatcher and someone wrote one in TCL in a week. Just to get something working. And they never got around to replacing it because it worked 'fine'. Turned out while everything else needed to be hyper efficient and scale the dispatcher not really.

Post by aeorgnoieang » Tue, Aug 13, 2019, 7:55 PM UTC

wellpast wrote: post #78

Raidion wrote: post #41

Earlier quoted context omitted.

But that's the point. It is a fuzzy thing. Software is built on business priorities, not technical ones. These align a decent amount of the time. Spending the extra time and money to set up tests is very much worth it. Is it worth implementing a cache layer in a system? One on hand, you have a better system that can handle more load, on the other, you've spent time that could be spent doing something else. Your syste…

> Is it worth implementing a cache layer in a system? This isn't a "Tech Debt" thing. This is a feature/scoping thing. Does my system need to handle 1M concurrent users? If so, support that. If not, don't support it. But we don't need the absurd concept of "Tech Debt" for effective analysis. We can be specific. We can be clear. Does my system need to support low latency in the face of 1M concurrent users? Yes or no.…

Post by poslathian » Tue, Aug 13, 2019, 7:59 PM UTC

TheLastPass wrote: post #101

davnicwil wrote: post #59

The article links tech debt to financial debt early on, and this is exactly what the analogy is - it is best to be as literal as possible about it. What is good debt? It's taking money from someone, promising to pay them back more money in the future, and using the original money to make even more money than that , so both you and the lender profit. Good tech debt is just the same. It's taking shortcuts now to save t…

One important difference between tech debt and financial debt, is that if the project you accrued a bunch of tech debt in gets killed for unrelated reasons before it's completed, your debt is forgiven. You never pay it off, and you never have to. When you're validating an idea, don't worry about making everything perfect. Worry about validating the idea. Once you're more confident that you're actually gonna do it lon…