How's that meaningfully different than performance and code cleanup cases? Frequently, a team know how to implement a feature in an efficient manner, but only has time for a low-performance hack job. Similarly, "code cleanup" is as much a code word for "not how I would have done it" as it is for "bad architecture that will start constraining us very soon".
Performance work is no different than new features: requirements change.
Code cleanup can mean many things. When talking about architecture, it could be a legit argument that due to requirement changes there needs to be a rethink. But that's not debt. That wasn't a conscious decision made in the past to do A instead of B knowing that B was the right choice, but not realistic at the moment.
When talking about large code bases that have been around, code cleanup is a young person's term that tends to imply they are smarter or know more than the previous set of programmers who worked on it. That's possible, but a bad argument. And it's insulting. Obviously the code has worked for quite a while successfully, so it can't be as bad as it's being made it to be (that's management playing devil's advocate). If it hasn't been working, the schedule should reflect fixing it. Maybe that requires a massive recoding, but maybe not.
Cleanup is not about how the code works at runtime, but how well it supports change. An abstraction that looked right at the time shows its cracks years later. Changes that should be simple and low-risk become intense and scary when they need to fit in with it.
It's not insulting. For one thing, the person proposing the change may very well be the original author. For another, you have the benefit of hindsight and access to information they didn't about what bugs would emerge, which features would be demanded, and how hard it would be to implement them. Of course you're going to see better ways of doing things than were visible on day 0.
Increasing speed and reducing risk for all future iteration is some of the highest impact work you can do; rather than shipping a single feature, you're a force multiplier for all the features developed by your team.
The only time it makes sense to skip cleanup is when you're content to just let the thing run, and don't see any changes in the pipeline.
> That wasn't a conscious decision made in the past to do A instead of B knowing that B was the right choice, but not realistic at the moment.
I'm thinking of cases where it was a conscious choice. $deity knows that I've made plenty of such decisions in my career - chosing a hacky structure A to meet a next month's release, while articulating to management that after that release, I'll need to redo it to structure B. Sometimes a bunch of high-priority requests took precedence, which made the system stick to A for far longer than it should. I understand that to qualify as both "technical debt" and "architectural issue".
I use code cleanup as a term very differently, as a programmer with 20 years commercially developing software..
My process often involves creating layers/versions of the code that improve till the stage it's production ready. It might be half a dozen or more iterations to get to production quality for complex code, and the latter versions involve a lot of 'code cleanup'!
This includes things like implementing TODOS, adding logging, and refactoring and refining the concepts, the naming, making the code more dry, better srp and generally elegant code I hope that someone else would be happy to inherit and maintain and extend. That someone is often me!
It's taking something that works, mostly, but has limited clarity and elegance and higher future costs to work with, and 'cleaning it up'. Like a home or worksite cleaning up after working gets you ready to use it or work there productively in future.
I do this in most codebases I work in for awhile as well, when there's clearly need for improvements in dry, srp, conceptual patterns and clarity.
Our industry jargon calls this refactoring, but cleaning up actually relates to other stakeholders than the highly trained engineers, so I will generally call it cleaning up.
I agree with you that newer engineers often want to rewrite existing working things for many wrong reasons - but I think the specific term code cleanup has a place.
I think it's interesting that you've noted it as a code smell for a junior about to wreck a significant amount of company productivity. That's an all too common problem these days as the majority of engineers are junior with less than 5 to 10 years due to larger numbers entering the industry. I'm interested in the 'successful' strategies experienced engineers have used to head this off at the pass in organisations with non technical management who often listen to the loudest voices if they can't truly understand the issues themselves.
>> "That's possible, but a bad argument. And it's insulting."
Firstly, there are people smarter than me, it's not insulting, especially if a person makes a real improvement. Or maybe I made a mistake.
Secondly, original designer had to make a decision with limited information and time. Now we have the benefit of hindsight, so coming up with a better one is hardly surprising.
It can be in certain cases, but it sometimes depends on the perspective. Abstractions are hard and usually need enough time to think about and several iterations to get right. They are usually much more obvious in hindsight.
Because "performance" is not related to "functionality". If you skip corners (eg. panic instead properly forwarding an error, hack a new implementation over an existing interface, etc), you induce a long term cost each time you have to figure out why the code is misbehaving.
Technical debt is all these architectural issues which incurs a long term cost because minimum deliverables had to be met. Also, the first response to "performance" is always gonna be "throw more CPU/memory", not "let spend a month dev-time to rearchitecture." Tech-debt is only getting addressed when hardware can't meet the requirement, "performance" is just a marketing argument to sell it to management.
Making code perform more efficient is easily analyzed as a feature. If the inefficiency results in end user delays then it can be directly traded-off against other feature requests, if it only impacts costs it can be fairly easily be determined whether or not it is worth devoting (very expensive) developer resources against.
Prioritizing improving performance for aesthetic reasons, that is because a "low-performance hack job" offends someone's sensibilities, likely means either: 1) the team is poorly lead or 2) doesn't have enough high value work to do.
