>This one really rings true. Every individual change you don’t push back on makes things slowly, incrementally worse until you end up with a pile of garbage. But do you really want to block someone’s change because they wrote some awkward, hacky code? After all, they’ve solved some problem for the business and it might only take an hour to clean up later.
That depends on whether hacky code is nicely contained or spreads it's bad influence all over the place.
I would totally ask to add a reference to the tech debt ticket right there to the code so it's clear it's not a good practice to follow and to make sure that the ticket is actually created and not scheduled to be created by adding an async job into a memory hole.
Half the time, just asking for that is enough for stuff to be straightened out right there, as it's easier than creating a ticket.
>Later never comes. Hacks get built on top of other hacks and that one hour improvement would now be a week long refactor. No one can justify that.
But that's sometimes okay, it's a lifecycle of software. If business doesn't schedule maintenance, then maintenance schedules itself. The job of a good engineer is to make business types in the know about and let them decide.
> But that's sometimes okay, it's a lifecycle of software. If business doesn't schedule maintenance, then maintenance schedules itself. The job of a good engineer is to make business types in the know about and let them decide.
It's complicated. I've worked on a product that had accumulated 15 years of tech debt. This all happened for very good reasons. The previous leadership often needed to ship features to get contracts signed and to make payroll.
However, paying that debt off had become very expensive and getting meaningful returns from these improvements took a long time. The most direct value came out of making tests more comprehensive and faster. However, beyond that benefits were only tangible over months to years and only if you worked on the right code area. In a large corporation leadership tenure in a role is often shorter than that. So the personal incentives for much of leadership was to just ignore the tech debt.
It's an extreme example but it's where you can get yourself.
Edit: I am honestly not sure I have a strong recommendation from this, other than "watch the tech debt and pay it off when you get breathing room". But then original company leadership AFAIK never paid most of the cost (if any?) of the accumulated debt and had AFAIK two(!) nice exits from it.
> I would totally ask to add a reference to the tech debt ticket right there to the code
99 times out of 100, they create the tech debt ticket, they add the comment, and multiple years later no follow up was ever scheduled in and the ticket eventually just gets resolved out as "wont fix" or is otherwise never looked at again.
I learned a simple trick. Document all the shit, invent a metric that shows a difference between a painful shitty service-component-whatnot and a good one. The next time you are asked about feasibility of a project touching the blob of pain, point to the document listing it's status as "needs maintenance". Guess what -- time to make it right is allocated more often than it's not and if shit goes south, I will be taken seriously the next time.
That's just business. When a tram line has to be constructed and there is a leaking something something that will sabotage it if not taken care of, it's taken care of and included in the funding.
> But that's sometimes okay, it's a lifecycle of software. If business doesn't schedule maintenance, then maintenance schedules itself. The job of a good engineer is to make business types in the know about and let them decide.
Or sometimes the code continues to encrust itself, like a pearl - or more likely, like a kidney stone - not fatally, but causing pain all the goddamned time.
That depends on whether hacky code is nicely contained or spreads it's bad influence all over the place.
I would totally ask to add a reference to the tech debt ticket right there to the code so it's clear it's not a good practice to follow and to make sure that the ticket is actually created and not scheduled to be created by adding an async job into a memory hole.
Half the time, just asking for that is enough for stuff to be straightened out right there, as it's easier than creating a ticket.
>Later never comes. Hacks get built on top of other hacks and that one hour improvement would now be a week long refactor. No one can justify that.
But that's sometimes okay, it's a lifecycle of software. If business doesn't schedule maintenance, then maintenance schedules itself. The job of a good engineer is to make business types in the know about and let them decide.