But if somebody somewhat naive comes along, and just pushes through with sheer effort, they might succeed where many experts have predicted a failure.
NoSQL is the biggest example of this. Ignore everything we learned about ACID and just use key-value stores with no transactions or relations. People can build their own if they need them, right? And duplicating data to work around missing relationships is not a problem because storage is cheap? Then we get an explosion of new databases, each of which solve a subset of the missing functionally problems, with varying degrees of success.
I suspect this came across as more snide than I meant it. Sometimes holding a treasured constraint is the wrong thing and the old guard of experts failed to understand that not every business problem needed the full solution. But it annoys me for some reason the attitude of “we just solved this problem that experts could not solve for decades” when the nuance is that only a subset of the problem was solved, with potentially extraordinary effort required to re-introduce those missing constraints.
Regardless, I don't think it's necessarily that the expert would not want to drop some design constraint. It's more likely that it is genuinely hard to decide, which of them to drop and which of them to keep, because there are so many and problems are complex.
But if you're somewhat new (not a beginner either), you don't see all these, and you can benefit from the ignorance. Unfortunately, I think it cuts both ways, it's far more likely that ignorance will actually hurt you. But for a small number of people, ignorance can lead to lucky innovation.
Shooting down ideas is not productive. Making sure ideas are realizable is.
This was two jobs ago. Razor sharp developer, could come up with any feature you asked him to. Which was the problem, if ideas didn't originate from him, good freaking luck getting him to work on it. He cost us to miss a few critical deadlines because of his refusal to let other people do their jobs unless it satisfied his demands, company refused to fire him because he had been around so long and carried institutional knowledge about the application but also refused to de-silo himself-thereby making the entire engineering effort dependent on his knowledge.
Guy went from a severely annoying veteran on the team to being given management duties over the team once our old boss retired due to health concerns (irrelevant to the job itself-he just drew a very unlucky health card). I and several other developers were out the door soon after because none of us wanted to report to him.
Company later got acquired. I like to peep in on their "About Us" company roster page every now and then. He's still there. But I've seen 3 different people in three years in my former role reporting to him show up on the roster, and then disappear and then get replaced by a new face.
"People don't quit jobs, they quit bosses".
Calcified engineers are more likely to enjoy the high-level corporate environment. Flexible ones leave to start companies, contract, whatever.
> the better an engineer gets, the better they are at shooting down every idea