3 ms·

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

by jboy55 7y ago

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)

theturtletalks 7y ago
If tech debt is inevitable, what’s the solution? Good internal documentation and rewrites every few years?
- rickbad68 7y ago
  a practice of constant refactoring..
qes 7y ago
And I would say that's an example of when it can be good to purposefully take on technical debt. In my experience there have been plenty of significant refactorings that simply would not have been done if we didn't allow ourselves to get into this state where there is simultaneously an old and a new way of doing something. Especially if it's an area that sees frequent addition - it's not helpful to have people constantly adding code in the old way while off to the side people are trying to create a new way and completely finish switching everything over to it before integrating. Managing risk and balancing other active tasks in the pipeline also push towards integrating smaller pieces over time while multiple ways of doing the same thing exist. But you need to have organizational continuity, which can be rare when everyone is trying to hop jobs for better salary every couple of years.

by jboy55 7y ago

theturtletalks 7y ago

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

rickbad68 7y ago
a practice of constant refactoring..

qes 7y ago

And I would say that's an example of when it can be good to purposefully take on technical debt. In my experience there have been plenty of significant refactorings that simply would not have been done if we didn't allow ourselves to get into this state where there is simultaneously an old and a new way of doing something. Especially if it's an area that sees frequent addition - it's not helpful to have people constantly adding code in the old way while off to the side people are trying to create a new way and completely finish switching everything over to it before integrating. Managing risk and balancing other active tasks in the pipeline also push towards integrating smaller pieces over time while multiple ways of doing the same thing exist. But you need to have organizational continuity, which can be rare when everyone is trying to hop jobs for better salary every couple of years.