Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Three Kinds of Good Tech Debt

engineering.squarespace.com

Post reply on HN
Print view View original

81–90 of 159 posts

Re: Three Kinds of Good Tech Debt

#81

Post by fireflies_ »

eikenberry wrote: post #76
tempestn wrote: post #63

Earlier quoted context omitted.

> I think mostly where it goes awry in the wild is people forgetting the paying it off part. Which also fits the financial debt analogy perfectly.

What would bankruptcy be analogous to... the business going under? Having to rewrite the application due to unmaintainable code?

Probably a rewrite – HNers always seem to have stories about being brought in to work on companies with incomprehensible rats nests of code that are impossible to extend any further. I bet that's pretty common, more common than technical debt actually forcing the company under.

Still if you really want to take the analogy further declaring technical bankruptcy could cause business bankruptcy (see Joel Spolsky). You probably want to refinance your debt and get onto a repayment plan (an incremental rewrite) instead.

Re: Three Kinds of Good Tech Debt

#83

Post by phantarch »

gmueckl wrote: post #31
julianozen wrote: post #6

Two points I really enjoyed: > Not Fixing All the Edge Cases We’ve all seen bugs that occur so rarely, and fixing requires destroying some part of the original design architecture. The ability to acknowledge these types of bugs as not worth fixing is liberating. > Err on the side of building too little because you can always build more later. Build things to be easy to throw away and replace; I find developers tend t…

Writing hacks and throw-away stopgap solutions is generally a bad idea in reality. The only time when it can actually be allowed is when it it concerns a feature that is a pure leaf in the system with nothing else built on top of it. If you violate this rule and build other features on top of shortcuts, two things will inevitably happen: you will have to replace the shortcut with a proper solution eventually (it is o…

Another way to say this could be if you decide to take the route of explicitly not solving an edge case or write throwaway code, that feature becomes a leaf until the branch of immature code can be pruned and a new, stronger one put in place.

Re: Three Kinds of Good Tech Debt

#84

Post by s_tec »

tempestn wrote: post #67
hoorayimhelping wrote: post #39

Earlier quoted context omitted.

> If the quick hack is well documented, written in a very encapsulated and removable way, who cares about removing it later. I do. I care very deeply about removing it later. The problem is that encapsulation is often mistaken as a strong justification for existence, and code that is written tends to justify its existence just by existing. That's to say that once code is in production, it's scary to delete. It's much…

It sounds like a lot of those problems could be solved, or at least mitigated, by better communication between these developers.

Right, except that communication between developers is the least scalable part of running a software team. For every new member you add, there are n existing developers to communicate with, so your communication costs go up as O(n^2).

If the goal is to grow a piece of software over time (as in many startups), any architecture that relies on "better communication" is doomed to fail, simply because it limits the size of the team that can handle it (and thus growth).

Re: Three Kinds of Good Tech Debt

#85

Post by [deleted] »

sorokod wrote: post #40
wellpast wrote: post #36

Earlier quoted context omitted.

Perhaps this isn't "Tech Debt" at all. Perhaps this is a long understood, well-known activity called Prototyping or Learning. Perhaps the concept of "Tech Debt" is just fuzzy thinking.

Yes, something like that. When a suboptimal solution serves a strategic purpose it is not TD.

[deleted]

Re: Three Kinds of Good Tech Debt

#86

Post by vinay_ys »

Nicely done. Good to see an engineering blog acknowledging tech debt openly.

I'm with you all the way until the last paragraph which short-changed the conversation a bit. Quoting a few lines to respond below:

>> Build things to be easy to throw away and replace; it’ll make your code more modular.

One valid strategy to manage debt is to declare bankruptcy or amnesty on debt – that is throw away the code (because this code is no longer needed). In domains where this possible, definitely use it. But in most real-world touching software domains this is not likely possible.

>> Good tech debt has clear, well-known limitations. Document these in code comments, READMEs, FAQs, and conversations with the people who’d care.

Doing tech debt accounting in a more formal manner is required to intentionally take debt. In the locking example, it is a design debt (not just a code debt). If the debt isn't document well and then it can become a ticking time bomb to be tripped by a clueless developer later.

Re: Three Kinds of Good Tech Debt

#87

Post by vinay_ys »

phantarch wrote: post #83
gmueckl wrote: post #31

Earlier quoted context omitted.

Writing hacks and throw-away stopgap solutions is generally a bad idea in reality. The only time when it can actually be allowed is when it it concerns a feature that is a pure leaf in the system with nothing else built on top of it. If you violate this rule and build other features on top of shortcuts, two things will inevitably happen: you will have to replace the shortcut with a proper solution eventually (it is o…

Another way to say this could be if you decide to take the route of explicitly not solving an edge case or write throwaway code, that feature becomes a leaf until the branch of immature code can be pruned and a new, stronger one put in place.

It doesn't become a leaf automatically. You have to force it to stay a leaf. If you don't find a way to do this, and if things grow on top of it, then you are in trouble. This is hard to do in most architecture patterns.

Re: Three Kinds of Good Tech Debt

#88

Post by jboy55 »

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 epiphany between the old code and the new code, you're more likely to run into the trap of the first example. Major epiphany's could be, 'wow, we really didn't need all of that extra stuff', or, 'we've duplicated so much code, we should re-organize this all'.

I've been at plenty of companies where you have to understand that the Perl code is really old and these components use that, the Mason rewrite was 80% done and is over there, the Next Gen code was in Ruby these components do that. But now, we're embarking on a new Node/React project to replace all of it, finally going to get rid of the tech debt! (Said with no sarcasm)

Re: Three Kinds of Good Tech Debt

#89

Post by theturtletalks »

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?

Re: Three Kinds of Good Tech Debt

#90

Post by vinay_ys »

marcosdumay wrote: post #27
julianozen wrote: post #6

Two points I really enjoyed: > Not Fixing All the Edge Cases We’ve all seen bugs that occur so rarely, and fixing requires destroying some part of the original design architecture. The ability to acknowledge these types of bugs as not worth fixing is liberating. > Err on the side of building too little because you can always build more later. Build things to be easy to throw away and replace; I find developers tend t…

Building things to be easy to replace often does not mean quick hacks. Quick hacks are most likely hard to trow away, not easy. Building things to throw away means componentizing your code, that is extra work overall.

You are right. You have to make architectural choices to build a soft layer that can absorb such hacky throwaway code that can be pruned easily later. Usually a hard platform layers sits underneath it and supports this. Following Conway's law, usually there are teams to build and enforce the platform constructs that are relatively debt free and there are teams that work on the soft application layer on top of those platforms where these throwaway hacks can be easily put. You have to design for this in your architecture. But if this strategy is right for your business domain, then once you make the initial investment, it will pay for itself multiple-folds. You will see this pattern in online gaming code bases.
Post reply on HN