DEV Community

Jesse Warden
Jesse Warden

Posted on

Refactor All The Time Instead of "Tech Debt Day"

You don't negotiate with Product Owners on time on technical debt vs. time on features. You refactor all the time, while building the features. Product Owners not giving you time aren't the ones at fault for the technical debt, you the coder are, for allowing the code to become a mess over time.

Learn Continuous Integration, Test Driven Development, and how to work in small batches. If you're on a legacy code base, same approach for new code, and additional acceptance tests for old code.

This article is written extremely well, with wonderful context, even utilizing mob programming, describing exactly what you shouldn't do. Don't create a culture that condones bad code. There will always be technical debt, but you should be tackling it all the time, not deferring to some negotiated time period.

https://blog.alexewerlof.com/p/tech-debt-day

Top comments (1)

Collapse
 
redbar0n profile image
Magne

So true.

«I have yet to see a company that isn’t running code in production that was [only] intended to be a proof of concept or quick prototype.» -- Jason Lengstorf

The idea of ‘Throwaway prototypes’ is a scam.

Stuff tends to stick around!

That’s why you shouldn’t take shortcuts, since «the incentive to fix things disappear after they are shipped», incurring tech debt.

You likely won’t get around to «polish that feature later», or «clean up the codebase», or «delete the prototype and start from scratch».

The pressure of moving forward is too great. Put tasks fully behind you!

Another story from the trenches:

Stick to high standards

One oft-repeated mantra around A/B testing is “it’s just a test, we’ll fix it later”. The idea here is that you build an MVP and gauge interest, and if there is, you build a better designed, better implemented version as a final version. In practice I have not seen that work, presumably for two reasons: the first is that the incentive to fix things disappear after they are shipped. This applies to all parties: engineering, design and product. It’s already proven to be an uplift, and spending time re-designing or re-factoring will feel unneeded. And things that feel unneeded — even if they are needed — will not happen, especially in the pressure cooker that is product engineering.

The second reason is that re-implementing an experiment, even redesigning it, could have impact on any formerly assumed uplift [the experiment outcome]. To be absolutely sure, you’d have to run another experiment, now with the production-ready implementation. Ain’t nobody got time for that, chief. And here’s the thing: the type of environment that needs to take shortcuts for the implementation of an experiment is also unlikely to allocate time to refactor or/and re-run a successful experiment.

What happens? You accumulate tech debt. Often not something that is clearly scoped, and quantitatively described. Debt that is hard to put a number on, and hard to make the case for it to be addressed. Debt that will creep up on you, until finally, everybody gives up and pulls out the Rewrite hammer.

-- Dario Gieselaar (@GieselaarD) in “The Engineering Problem of A/B Testing”, levelup.gitconnected.com/the-engin...

Also sourced from my previous tweets:
x.com/magnemg/status/1284139466777...
x.com/magnemg/status/1366700117978...