DEV Community

Refactor All The Time Instead of "Tech Debt Day"

Jesse Warden on January 08, 2024

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. P...

Read full post

Magne • Jan 10

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...