Not saying this is you or GP, but I've dealt with enough juniors who just thought they're really smart and awesome but lacked any sense of what it's like to develop software for actual, normal people. They couldn't grasp that you don't just break your software for 20% of your userbase because it results in a cleaner database layout or nicer abstraction layer for something internal. "No I know what I'm doing, look I have this github project with 500 stars and none of the super techy people who use it ever complained when a new release broke something"
Yeah, no.
Usually these people come in two flavors: Those actually smart and developing an understanding for what it means to sell software and have customers with demands, and those who live in their little bubble where they're the most awesome person on the planet, and everybody else is just retarded. Halting all development for a year and refactoring everything according to what they think would be way superior after spending 5 minutes with the codebase is obviously a sane thing to demand.
And I usually try to let them fall into this trap in a controlled manner, like when it's a relatively unimportant component/feature, or just one customer where I can more or less directly relay the expected complaints to the junior dev. Usually playing the "this guy is responsible for your paycheck" card makes something click after a while.
>Halting all development for a year and refactoring everything according to what they think would be way superior after spending 5 minutes with the codebase is obviously a sane thing to demand.
Sure, but this only paints one extreme. It's fair to expect adults to realize money has to come from somewhere, and halting any development and even bugfixes won't keep customers. On the other extreme, we have sales and management pushing insane demands, which get tacked onto already poor code, degrading further, causing bugs in the future, increasing the risk factor, on top of already taking more than 5x as long as it reasonably should with no difference in features whatsoever. Which further escalates into high turnover rates, worse code quality, dissatisfied employees, no seniority willing to come in unless they get paid big time, and more. It's a fine line no matter how you slice it. Both extremes can run a company into giant losses or even bankruptcy.
Additionally, demands on juniors to prove a business case are often far higher than their seniors or managers, despite giving juniors less resources to do so. With such a simple mechanism in place, it is fair to assume the juniors who do go through the trouble of speaking up care about the quality of the product and their responsibility in the matter. Likewise, I've seen plenty of seniors fall into the same trap you described, either halting all progress or spending (read: wasting) months developing a strategy out of analysis paralysis only to not even have a business case. If anything, they tend to be able to do this even easier, since they are met with much less resistance thanks to their reputation and/or authority.
Yeah, no.
Usually these people come in two flavors: Those actually smart and developing an understanding for what it means to sell software and have customers with demands, and those who live in their little bubble where they're the most awesome person on the planet, and everybody else is just retarded. Halting all development for a year and refactoring everything according to what they think would be way superior after spending 5 minutes with the codebase is obviously a sane thing to demand.
And I usually try to let them fall into this trap in a controlled manner, like when it's a relatively unimportant component/feature, or just one customer where I can more or less directly relay the expected complaints to the junior dev. Usually playing the "this guy is responsible for your paycheck" card makes something click after a while.