Hacker News Reader

Comment by throw3823423 | Hacker News Reader

It's a matter of letting things degrade so that the maintenance becomes outright firefighting. I am currently working on a project where a processing pipeline has a maximum practical throughput of 1x, and a median day's for said pipeline is... 0.95x. So any outage becomes unrecoverable. Getting that project approved 6 month from now would have been basically impossible. Right now, it's valued at a promotion-level difficulty instead.

At another job, at a financial firm I got a big bonus after I went live on November 28th with an upgrade that let a system 10x their max throughput, and scaled linearly instead of being completely stuck. at their 1x. Median number of requests per second received in dec 1st? 1.8x... the system would have failed under load, causing significant losses to the company.

Prevention is underrated, but firefighting heroics are so well regarded that sometimes it might even be worthwhile to be the arsonist

View on HN

Intuitively, "fixing life-or-death disasterss is more visible and gets better rewards than preventing them" doesn't seem like it should be a unique problem of software engineering. Any engineering or technical discipline, executed as part of a large company, ought to have the potential for this particular dysfunction.

So I wonder: do the same dynamics appear in any non-software companies? If not, why not? If yes, have they already found a way to solve them?

> If yes, have they already found a way to solve them?

A long history of blood, lawsuits, and regulations.

Preventing a building from collapsing is done ahead of time, because buildings have previously collapsed, and cost a lot of lives / money etc.

I remember my very first day of studying engineering, the professor said: "Do you know the difference between an engineer and a doctor? When a doctor messes up, people die. When an engineer messes up LOTS of people die."

Outside of software, people designing technology are engineers. Although by no means perfect, engineers generally have more ability to push back against bad technical decisions.

Engineers are also generally encultured into a professional culture that emphasizes disciplined engineering practices and technical excellence. On the other hand, modern software development culture actively discourages these traits. For example, taking the time to do design is labeled as "waterfall", YAGNI sentiment, opposition to algorithms interviews, opposition to "complicated" functional programming techniques, etc.

That's a very idealistic black-and-white view of the world.

A huge number of roles casually use the "engineer" moniker and a lot of people who actually have engineering degrees of some sort, even advanced degrees from top schools, are not licensed and don't necessarily follow rigid processes (e.g. structural analyses) on a day to day basis.

As someone who does have engineering degrees outside of software, I have zero problem with the software engineer term--at least for anyone who does have some education in basic principles and practices.

I have yet to see, with the exception of the software world, engineering with such loose process.

As someone who was a mechanical engineer in the oil business, I think you have a very positive view of engineering processes in general.

It's common to start constructing buildings before the design is even complete. And there can be huge "tech debt" disasters in civil engineering. Berlin Airport is one famous example.

>It's common to start constructing buildings before the design is even complete.

Of which the Sydney Opera House is one of the better known examples.

How do you think we got into this climate change mess?

Yeah but if you had a release target of dec 15 and it crashed dec 1st and you could have brought it home by the 7th you would have been a bigger winner. Tragedy prevented is tragedy forgotten. No lessons were learned

Reply on news.ycombinator.com