> Someone who says no for too long doesn't last.

I actually think the engineering manager is probably in the wrong there, because if killer feature X is that critical to sales, then it needs to be prioritized in among the tech debt. It doesn't matter that the codebase health is not great if sales plummet. Being a good employee means sometimes prioritizing the health of the business and not the ergonomics of the work environment. And being a good manager means understanding when the health of the business is really at stake or whether the sales team is just throwing shade because they don't want to sell what the company has.

I generally believe engineering is right in this sort of hypothetical. But, at some point if they really are focusing on code quality… I mean, ultimately the point of code quality is to deliver features/reduce maintenance over the long run, right? So if they really are doing a good job of improving code quality, over the long run they should have a good relationship with management and the political capital to make this request.

From an outside point of view, focusing on code quality and playing videogames instead of working look identical over the short term (or more realistically, working on little niche bits of the code or doing tidying-up busywork that doesn’t really improve the overall quality of the project—it could legitimately be hard to tell the difference). Of course, it should eventually become apparent that the latter group didn’t actually accomplish anything in that time.

“How do you balance the,” I guess it is a social thing/judgement call ultimately.

Code maintainability could be analogized to 5S in the manufacturing world. As a hypothetical let's say someone started assembling some product on the bare concrete warehouse floor because they had a pressing order to fill. A few months later it's just a mess of parts strewn about the floor that workers have to sift through to find the correct pieces for the assembly. The goal of a business is to make money, not have a clean workspace as a sibling comment mentioned. Ultimately this would leave a company vulnerable to a competitor who doesn't have such an expensive and inefficient production process though.

I've worked on many, many features that never recouped their engineering cost despite the absolute assurance by sales that it was necessary. It would have been more effective long term to work on improving code maintainability so that we could better capitalize on features that substantially affect revenue in a positive direction. All too often I see that code maintainability only matters to the business when features can no longer be reliably and quickly delivered, but by then it's usually too late to really change course. This sort of balance also tends to drive all of the new fancy frameworks that cause so much churn as the signal from the business to engineering is that engineering needs to be able to pump out features very quickly but will not be given time to focus on maintainability so naturally this gets outsourced to someone else.

To be fair, I have also been involved in an emergency project that if it wasn't completed in a very tight time frame the company would have lost 30% of their revenue and there would have been substantial workforce reductions. We did not focus on maintainability in this situation rather we focused on saving the company.

Everything is a trade-off in business. My experience tells me companies generally focus on short term profit over long term concerns and there's very little in the way of feedback mechanisms that allow an inspection of these decisions in aggregate to see if the right balance is being struck.

Someone who says yes for too long, doesn't blast- out of the airframes plug.

"Everyone thinks their job in the Silo is the most important. Mine actually is." -- Juliette Nichols (also some Software Engineers)