[tristor]

Speaking as a PM and a former Eng, if you could get 1.5x your features at this trade-off, the topline revenue that those features drive could very likely result in significant additional resources to provide to dev. I realize you can chase your tail with tech debt, but you're calling this "alright" code, not horrible code. I'd take that trade-off in either role I had.

[zer8k]

That's your PMness speaking.

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

[tristor]

This rant doesn't seem to address my comment, and seems to be an expression of your existing anti-PM bias.

[deepspace]

> Leave decisions like these to the engineers.

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

[Apes]

1.5x the features, 3x the code would roughly result in 1/3 development velocity, 3x bugs, and 3x incidents going forward.

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.

[etblg]

> significant additional resources to provide to dev.

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.

[tristor]

> Ah sweet, even more problems to deal with then.

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.

[HWR_14]

I'm amazed that as a PM you think features linearly drive revenue. This has not been my experience.

[tristor]

It greatly depends on what the "features" are. We're being intentionally very hand-wavy here. If you are adding features that are incremental for existing customer markets, then of course it's not going to drive linear revenue (it may not even drive /any/ additional revenue), but if those features open up new markets and use cases it can grow revenue beyond linear for effort. It all depends, and we're not being specific enough to say one way or the other since this is a contrived hypothetical with vague inputs.

[jashmatthews]

Engineering output doesn't even scale close to linearly, though. You _might_ grow revenue 1.5x but now you have 3x as much code/system and need 6-9x as the engineering headcount.

We probably just took a nice small/medium profitable business and completely fucked it.

[commandlinefan]

> more problems to deal with

But that's not _his_ problem, and he already got his bonus for "hitting the date".

[szundi]

Of course you can always run out of time and go bankrupt and these people could go to other companies to work on a probably even worse codebase. Also everyone lost years of their lives chasing the CEO into perfectness

[thayne]

Even if the code is the same quality as existing code, having 3x of it will slow down development considerably. And will probably make developers less happy with their jobs, and increase churn. And hiring more devs will initially slow down development even more.

[woleium]

Alright code is a step up for some projects I've seen, lol.

[vsareto]

Our field’s (lack of) training sucks at teaching good code though.

Plus some styles have changed over the years. If we keep changing quickly, good code is just a fad.

[szundi]

Exactly

[gymbeaux]

If I had a dollar for every time a SWE was promised “resources” to address tech debt I could probably retire. If you’re “not that PM”, good on you, but any seasoned SWE hears “we’ll address the tech debt {in the future}” and either laughs or cries on the inside.