PMs never consider who will manage the code down the line. They never consider the implied difficulty multiplier because if you can't party poker it, you can't build it! That's what the agile ninjas say! Code that is "kinda bad but ok" will end up being the cause of a SEV0 eventually. This kind of tradeoff is made by management because the entire field of software engineering is a joke to them.
There's a trade off to be made. But it isn't the one posited. Creating code that is manageable implies it's better than "kinda bad but ok" but not all the way to a magnum opus in software engineering.
Leave decisions like these to the engineers. If management isn't willing to give "significant additional resources" to engineers they get what they pay for. Enjoy your extremely high turnover. Of course, it'll never be your fault. The engineers will also suffer the consequences. It would be nice to see even one PM eat shit for their terrible project management decisions done in the name of "agile".
Maybe for a 1.1x increase in features, but for 1.5x (provided the new features solve actual customer problems), I will choose the genie every time. /PM
Even assuming all your developers are magically given a solid understanding of the new code, all remaining velocity will be entirely consumed by bugs and incidents. No more feature development will occur.
You could try to grow to outrun the code debt you've just acquired - but that's what literally every start up tries to do, and less than 10% succeed.
The most likely outcome is that the company would enjoy a one-time massive feature feast before slowly dying over the course of 5-10 years or so.
Great if you're a founder looking for a quick exit or some other position that is super focused on short term growth, I suppose.
Ah sweet, even more problems to deal with then. More people to onboard to support you in writing the 3x more code, more managers needed, or more strain on the managers, etc. We'll just fix it by hiring even more people.
Whether or not adding more people is a problem greatly depends on the existing workload and where in the development cycle those folks are added. It also depends on the quality of the people. My comment was certainly not advocating for putting more meat into the grinder in favor of chasing the mythical man month.
My point was more that if you can magic your way into 1.5x the features for 3x the code, and it's "alright", you can probably add 1.5x to the top-line revenue over the same time frame. A 1.5x increase in top line revenue, especially at a larger organization, is absolutely massive and opens up many possibilities, including hiring significant additional headcount. The headcount comes in /after/ this magical moment, not prior to or in the midst of. And yes, if you have 3x more code, you'd probably want more people to help manage resolving technical debt, fixing bugs, and generally dealing with the ongoing keep-the-lights-on work that is inherent in that.
We probably just took a nice small/medium profitable business and completely fucked it.
But that's not _his_ problem, and he already got his bonus for "hitting the date".
Plus some styles have changed over the years. If we keep changing quickly, good code is just a fad.