ive never actually seen someone get fired for making some deep architectural software mistake. its alway for moving too slow, or "low code quality". i think people that were promoted for building systems that turned out bad, should be demoted
Because businesses, as a rule, value moving fast. Being first to market makes money and generally results in winning.
Oftentimes the circumstances are "we don't know the requirements", not because of shitty management, but because the problem is inherently hard to define.
The business conditions that do heavily penalize bad architectural decisions, like physical structural engineering, can suck to work in compared to SWE.
It takes a decade or more before you're trustworthy enough to architect a building and there's a million layers of approvals. Then it takes years before groundbreaking, and years more as the building increases in size.
Your whole life might be dominated by a single large project like Hudson Yards, which has been floating around as an idea since 1956. The most recent proposal started in 2006, broke ground in 2012, and another 6+ years to finish. Then when companies were about to move their offices there, COVID-19 happened and the leases fell through.
I'd rather the system that gives average SWEs regular opportunities to lead large projects from scratch and make mistakes.
I think you are underestimating how many product problems at big companies are actually bad technical debt. They cant release new features or evolve the offering because the systems are too complicated to change. 1 year of quick development could stunt the whole org for the next five years.
The good news if you take 2 years to ship the system "properly" then you won't have to re-factor it because the company went out of business or that product was too late to market.
There is a phrase "million dollar problems". You do stuff at your startup that will take a million dollars to fix because it doesn't scale.
The point is that if your startup doesn't get to that scale then it doesn't matter. If you startup does reach that scale then you have plenty of money/people to spend a million dollars fixing it.
Replies like yours gloss over nuance. I don't mind prioritizing time to market as a programmer; I am not clueless, I understand that imperfect product that pours money into my employer's coffers is infinitely better than it sinking and we all get fired out of necessity.
My problem comes from the fact that the leadership _never_ compromises and never allows us to avoid at least some crises that are extremely easy to foresee (and have happened like clockwork in 95% of the cases where I or other colleagues have predicted them).
Again, sure, let's go to market and start making sales. I completely agree. But scolding a dev for fixing a DB schema anomaly that slows down ~40% of _all_ feature requests and that it took him the grand day or two to do so, is not just myopic. It's moronic.
---
Even shorter / TL;DR version: If the balance of power was 80% leadership and 20% engineers, I'd still be completely OK with that. But wherever I go the "balance" of power is more like 99% leadership and 1% engineers (and that's only when stuff really has hit the fan; they'd take away that last one percent as well if they could).
That is the problem. There's no balance. No compromise. Just people barking orders.
It is not only being first. It also is about responding to customers - not fun part is your customers don’t care about your app. They have to use dozens of different apps on daily basis, so when you have customer interaction you better be able to do stuff right there because they might be available in 3 months or next year to talk about your app.
I don’t like all the fantasy about “just talk to the customers” - nah it is not just, it is super hard to get their time.
You can’t often demote them because usually the people responsible for bad initial design decisions left the company years ago with a desperate need to go and start a new mess somewhere else.
All systems eventually turn bad. The idea that you can gold plate something so it won't is naive. It isn't about getting it right from the start, its about having the will to change it once your system or uses evolve into something that turns it wrong.
> i think people that were promoted for building systems that turned out bad, should be demoted
Nope, in the same vein of "lording" over others, they become the expert of knowledge of bullshit. The environments that allow such behavior have already engrained reward of such behavior.
