Why senior engineers let bad projects fail

Years ago I was very peripherally involved in a large project for which everyone in the trenches, so all the devs working on it, knew it could never work. Heck, even the sales guys could explain, with technical justification, why it wasn't going to work. But they were getting paid, and jobs weren't exactly readily available at the time, so they all slogged on until eventually it failed as predicted. AFAICT it was a frog-boiling thing, it was easier to stay, and keep getting paid until the money ran out, than to stick your neck out and point out that there was a problem.

Just going to be brutally honest - we lost the art of software design and architecture. Clean code is pretty much dead. As someone who has contributed to many OSS projects and built frameworks...I just don't see this anymore. All of my colleagues have moved on. Conferences used to be full of great info and research, but the story flipped there. Now they are all about marketing, treating speakers like crap, not willing to cover various expenses because they believe they are doing the speaker a favor. Also factor in the industry supply and demand issues and desire to just "move fast and break things" and voila - we have a lot of really bad software.

I mean the supply and demand problem was so bad that you had people so narrowly focused that their expectations were absolutely wild. Expecting wild titles out of college or practically out of college. How many "senior" engineers are there who have 3 years of experience or less? How many principals? CTOs? Tons. It's wild and a horrible expectation. Then this cohort of people couldn't possibly fathom actually learning and putting in time so they attacked the people who were simply around longer. I guess ageism but really that naive and toxic phrase you'd hear all over "jack of all trades, master of none." People just couldn't get over the fact that others knew more than a week's worth of YouTube content...and I get it, the large companies hired many people to do one specific job. It's just how the industry supported the insane demand. You "specialize" ... If you want to call it that. As a result, I do not often hire people from large companies because they expect way too much money and do far too little.

So all of this is to say quality has fallen off a cliff and very few know any better. It's really a result of industry demand.

I think many senior engineers let bad projects fail because they don't actually know how to save them. But yes, I'm agree, there's also no incentive.

Here's where I love AI. I'm hoping that AI can help fill some skill gaps, provide education, and separate the people who have motivation from those who don't. At the end of the day, I hate to say it - many engineers took advantage of people. Maybe not intentionally of course, it what was the market would bear. I think AI is going to put an end to the gravy train and as a programmer of over 20 years? I'm thrilled.

Will AI prevent bad projects though? No. Because we still have the same problems. Few programmers are going to plan, communicate, and even bother to put forth the effort to ask about software design. They're going to crank out AI slop.

You know my bet? My bet is that product minded people who didn't understand coding will end up out performing most programmers. In fact, the more junior people on my team absolutely shred many of the "senior" programmers. So much so that I'm faced with a very very difficult gut wrenching challenge. Upskill the "senior" programmers or let them go, because it's just bad for the business when you just look at the numbers. I wouldn't be doing my job and be protecting the company if one of those two outcomes didn't happen. I'm not going to protect people who don't want to lift a finger.

A great reckoning is coming. I think there's going to be a Renaissance from an unexpected cohort of people who will produce good projects again. It won't be the "senior" programmers.

I'm in the middle of watching this happen. The business owner chose a "low code" platform due to cost and "speed", against my team's recommendations, and now they're needing to do all sorts of customizations which are essentially massive hacks. My team is sitting in our corner writing typescript deploying a dozen or so times per day, and this other team of "low coders" is sitting there trying to figure out how to make curl do things it shouldn't be doing with prod deployments like once per month.

That's insane. I think about 80%+ of the projects I see attempted succeed in at least some limited fashion. Even the failures in retrospect produced some insight into the right way forward and were necessary as part of research.

From the article:

> You rarely get credit for the disasters you prevented. Because nothing happened, people forget about it quickly.

There is another problem left implicit in the article: clueless people doing drive-by project reviews without any context or understanding of the whole problem domain, and proceeding to give unsolicited and unreflected advice supported by partial knowledge.

Also, sometimes projects with a perfect design end up failing for some reason or another, and projects doomed to fail end up pulling through and succeeding, even if they pile up technical debt. The truth of the matter is that software is soft and can adapt to changes in requirements and design, and with enough work anything can be made to work. Thus any observation on "failure" ends up being superficial opinions based on superficial observations.