If you need a metaphor to understand this perspective: there's a difference between building a bridge that gets some cars over it, and building a bridge that will continue to get cars over it, in thirty years, while accounting for the expected investment of maintenance over those thirty years, and supporting an expanded pedestrian and bike lane added ten years down the line, to the best of the ability of the engineer during the initial planning, while keeping build costs under control.
Yeah; working only with Good code is a luxury. But simultaneously, admitting to recognize "It Works" as the most important metric to evaluate good engineering practices by is quite literally what led to the East Palestine disaster last week. Being able to abscond from the responsibility of the repercussions of your "It Works" solution is also a luxury; or, charging those "obscene contracting rates" you talk about.
Software Engineering is nascent. We don't always know, and even less often have a good shared language to talk about, what is "The Right Decision" in every context. That isn't an excuse to not try.
You have the wrong metaphor, since bridge projects are all more or less the same, but software projects aren't.
I like the shed and skyskraper metaphor better. It makes a clear distinction that some projects are sheds (can be a single script) all the way up to skyscrapers.
Some projects don't even need to be extended afterwards, like most computer games.
It doesn't really work with either metaphor. Somebody building the Golden Gate bridge or skyscraper knows that they're building it and has a clear picture of what it will look like once it's finished.
Software is more like a settlement. It may start out looking like a village and end of life looking like a village or it may catch a wave and end up looking like a megalopolis - perhaps a clean, well organized one like Singapore or a disastrously organized one with chronic traffic, corruption and crime like Lagos.
A lot of people out there think that they need to make space for a subway in their village coz it's Definitely Coming One Day while others don't have time to build a subway even while they suffer 7 hour long traffic jams.
I simply won't take the job if someone demands I do a rush job of programming train braking systems.
It seems like you're reading into what I'm saying a commitment to "not trying" and "[a] metric for evaluating good engineering practices". I'm absolutely not, I'm arguing against the kind of sneering belief in self-superiority that leads some software developers to feel like someone who uses a particular method or way of making working software, "sucks".
There’s a balance here, and it’s important to recognize that often the “but the code works” mantra is used by the lazy or incompetent to justify poorly written code.
I think everyone has been burned by something different, and sometimes we read internet comments that are easy to misinterpret as supporting The Thing We Hate That Burned Us.
Yeah; working only with Good code is a luxury. But simultaneously, admitting to recognize "It Works" as the most important metric to evaluate good engineering practices by is quite literally what led to the East Palestine disaster last week. Being able to abscond from the responsibility of the repercussions of your "It Works" solution is also a luxury; or, charging those "obscene contracting rates" you talk about.
Software Engineering is nascent. We don't always know, and even less often have a good shared language to talk about, what is "The Right Decision" in every context. That isn't an excuse to not try.