3 ms·

Your example is so decoupled from reality that it's misleading. Most catastrophic problems in large systems aren't "I made a thing and it's buggy," or "I made a

Your example is so decoupled from reality that it's misleading. Most catastrophic problems in large systems aren't "I made a thing and it's buggy," or "I made a thing that steals SSNs." Most of them are some variation of "It used to work this way, but this upstream dependency changed in a way that we are ok with, and now it works a different way, and we have no visibility into what that may change for downstream dependencies, so hopefully they are aware of the same things we are and act accordingly." Bugs can come from many different people signing off on changes that are often, in isolation, fine. Imagine if all buildings had to constantly be retrofitted to support a new structures on, below, inside of, around, and next to them, and every retrofit had a different engineer/architect/etc. No civil engineer would ever sign off on anything.

deleted 4y ago
[deleted]
ryandrake 4y ago
Yours is a good example! I have in a past life actually used the "you wouldn't bolt a new floor onto a building" argument successfully to push against feature creep. I think even a small amount of accountability would definitely start some much-needed conversations at software companies about things like "do we really need to retrofit this thing onto that working thing?" and "do we fully understand our dependencies and the consequence of merging from them?" and software quality would be better for it. If the consequence of a bug is low, go for it--the accountability should be low, too. EDIT, just to add another example. I remember when I felt rushed and checked in some client code that did not implement exponential backoff for request failures--it just retried. Of course that code made it to production and our customers started DDOSing our server when a brief outage happened. I felt terrible about it and honestly believe I should have been fired for it. Yes, management rushed me, but they're not the ones that wrote the code. They're not the ones that made an amateur-hour error. It was me.
- mangamadaiyan 4y ago
  > I felt terrible about it and honestly believe I should have been fired for it. > Yes, management rushed me, but they're not the ones that wrote the code If you felt so strongly about it, you could have quit. Why wait on management to fire you? It's fairly easy to blame engineers for everything that goes wrong. Engineering doesn't work in a vacuum, the system and processes have to have guardrails in place that prevent lapses in quality, including security, from reaching the customer. When such guardrails have been systematically dismantled in favour of "improving productivity", the management - which removed the guardrails - becomes the culpable entity.
- scns 4y ago
  Interesting. Great that you want to take full responsibility for your work. There is always two sides to a coin though. Strange to me that you scapegoat yourself that hard. Reminds me of the story, where someones error cost the compny millions. He gets called in his superiors office. He says something about resignation. His boss responds: "What? We just invested millions in your education". Every error we still have to make, is a treasure waiting to be dug up IMHO.
- Izkata 4y ago
  > Yours is a good example! I have in a past life actually used the "you wouldn't bolt a new floor onto a building" argument successfully to push against feature creep. I've seen a few houses built on top of apartment buildings though.
ok_dad 4y ago
> had to constantly be retrofitted There’s your problem. You can’t constantly change software contracts without causing bugs. If you’re liable for the code chances are things will slow a bit. Good! We need to develop software slower.
- BobbyJo 4y ago
  > You can’t constantly change software contracts without causing bugs You can't write software without causing bugs, static requirements or not. The software that goes into air/space-crafts is written this way, and it still breaks occasionally. Sometimes bugs are circumvented with hardware because it's cheaper and more reliable than making the software change. Buildings have fault tolerances. You can use the wrong amount of something, or put something in the wrong place, and have it still work. If buildings had to be designed and built exactly corrects or they fell apart, we wouldn't have buildings. > We need to develop software slower To each his own. Most software is fine having bugs. I'd rather have a modern web browser with a few bugs than have an ascii-only command line browser that works flawlessly. The U.S. economy would agree with me there. The software in your pacemaker or car, sure, balance safety and speed to save the most lives/time, but most software operates in domains with far lower stakes.

deleted 4y ago

[deleted]

ryandrake 4y ago

Yours is a good example! I have in a past life actually used the "you wouldn't bolt a new floor onto a building" argument successfully to push against feature creep. I think even a small amount of accountability would definitely start some much-needed conversations at software companies about things like "do we really need to retrofit this thing onto that working thing?" and "do we fully understand our dependencies and the consequence of merging from them?" and software quality would be better for it. If the consequence of a bug is low, go for it--the accountability should be low, too. EDIT, just to add another example. I remember when I felt rushed and checked in some client code that did not implement exponential backoff for request failures--it just retried. Of course that code made it to production and our customers started DDOSing our server when a brief outage happened. I felt terrible about it and honestly believe I should have been fired for it. Yes, management rushed me, but they're not the ones that wrote the code. They're not the ones that made an amateur-hour error. It was me.

mangamadaiyan 4y ago
> I felt terrible about it and honestly believe I should have been fired for it. > Yes, management rushed me, but they're not the ones that wrote the code If you felt so strongly about it, you could have quit. Why wait on management to fire you? It's fairly easy to blame engineers for everything that goes wrong. Engineering doesn't work in a vacuum, the system and processes have to have guardrails in place that prevent lapses in quality, including security, from reaching the customer. When such guardrails have been systematically dismantled in favour of "improving productivity", the management - which removed the guardrails - becomes the culpable entity.
scns 4y ago
Interesting. Great that you want to take full responsibility for your work. There is always two sides to a coin though. Strange to me that you scapegoat yourself that hard. Reminds me of the story, where someones error cost the compny millions. He gets called in his superiors office. He says something about resignation. His boss responds: "What? We just invested millions in your education". Every error we still have to make, is a treasure waiting to be dug up IMHO.
Izkata 4y ago
> Yours is a good example! I have in a past life actually used the "you wouldn't bolt a new floor onto a building" argument successfully to push against feature creep. I've seen a few houses built on top of apartment buildings though.

ok_dad 4y ago

> had to constantly be retrofitted There’s your problem. You can’t constantly change software contracts without causing bugs. If you’re liable for the code chances are things will slow a bit. Good! We need to develop software slower.

BobbyJo 4y ago
> You can’t constantly change software contracts without causing bugs You can't write software without causing bugs, static requirements or not. The software that goes into air/space-crafts is written this way, and it still breaks occasionally. Sometimes bugs are circumvented with hardware because it's cheaper and more reliable than making the software change. Buildings have fault tolerances. You can use the wrong amount of something, or put something in the wrong place, and have it still work. If buildings had to be designed and built exactly corrects or they fell apart, we wouldn't have buildings. > We need to develop software slower To each his own. Most software is fine having bugs. I'd rather have a modern web browser with a few bugs than have an ascii-only command line browser that works flawlessly. The U.S. economy would agree with me there. The software in your pacemaker or car, sure, balance safety and speed to save the most lives/time, but most software operates in domains with far lower stakes.