4 ms·

Just because a piece of software won’t kill people if it fails, it doesn’t mean that we should drop the ball on trying to make it as reliable as possible. And I

by bezout 6y ago

Just because a piece of software won’t kill people if it fails, it doesn’t mean that we should drop the ball on trying to make it as reliable as possible. And I’m not talking about OSS. I’m talking about the software you pay for. You are giving away your money and you expect something as valuable in return.

CaptArmchair 6y ago
From the article: > Once you accept failure is inevitable and commit to avoiding the concatenation of failures that causes catastrophes, you—and your organization—need to decide what risk looks like and what to prioritize. If everything is the most important thing, then nothing is. [...] > The more complex the system, the more likely it is that some part of it is broken. As engineers, we’re at the apex of literally millions of hours of design and engineering time to help us, and our users, with everything from finding our phone to continuously integrating our code. We have to assume that some of that infrastructure, and some of our work, is broken. > If we accept these imperfections, we can work toward building resilient systems that can handle a little static and deal with flawed foundations without falling over. We don’t stop working toward perfection just because it’s impossible. The author's point isn't to throw up arms in defeat. Her point is to "courageously change the things you can change, accept the things you can't change, and find the wisdom to know the difference between the two". There will always be tension between striving for the ideal world where everything is always written to perfection using the latest innovative technology, and the real world where legacy code and technical debt are par for the course. It's all too easy to compare software on which lives depend (avionics, healthcare,...) with video games, short-lived marketing apps or business suites. "value for your money" means very different things to different people in different contexts.
- MattPalmer1086 6y ago
  I agree with your main point that the article is not suggesting giving up. It does amuse me though that an ideal of perfection is having no legacy code, all written with the latest technologies. I once spent some time refactoring some really old gnarly code to be beautiful and well designed. The rest of the team looked on in horror and asked why I was replacing highly reliable, battle tested code that had been in successful operation for nearly ten years!
  - mgkimsal 6y ago
    > The rest of the team looked on in horror and asked why I was replacing highly reliable, battle tested code that had been in successful operation for nearly ten years! And they were probably correct in doing so. If people are expected to be making changes to it, but it's generally working well otherwise, adding explanatory docs, notes and tests around that code would likely be far more valuable than rewriting it. You have to understand the problem before rewriting anyway - writing up that documentation and supporting evidence is often a better goal than "rewrite" when a system is working pretty well in service. I've also seen the "don't rewrite it!" on code that is breaking/wrong constantly - like... daily. People have adjusted habits around it, and making a change is seen as 'risky' but there's a lot of unacknowledged operational debt that can be cleaned up with updating the code (investigate, doc beforehand too).
- throwaway346434 6y ago
  The tradgedy of flawed paid software is the people who pay, and the people who use it are often different. Accepting this after seeing it is equivalent to saying "I am okay with trading misery for profit". That bit isnt a software problem, but its not a good look!
- mgkimsal 6y ago
  > courageously change the things you can change, accept the things you can't change, and find the wisdom to know the difference between the two And trying to tell a client to 'accept the things they can not change'... doesn't often go over too well. Harder still in some cases because, technically, almost anything can be changed, but estimating the time/effort/cost is a difficult task in itself.
  - afarrell 6y ago
    > doesn't often go over too well Beware the difference between being nice and being genuinely kind. The latter requires the courage to be willing to upset somebody and lose a lucrative contract.
    - CaptArmchair 6y ago
      It's true that anything can be changed. Improvement, however, is a form of value attribution. It's always in the eye of the beholder. It's totally valid to hold different ideas on how things ought to be improved. It's important to acknowledge that and bring that to the table. Even worse, compromising for the sole sake of signing a contract is a risky proposition. Projects fail because visions and ideas are being sold without acknowledging the reality represented in the limitations of existing technological solutions or infrastructure that needs to be maintained.
namelosw 6y ago
The customer of course desire high-quality product they have paid for. The problem is more often than not, the guy who pays developer salaries wants the developers to spend less time on polishing.
- snarfy 6y ago
  Very true, and the guy paying the salaries is wrong. The customers want the polish without knowing that's what they want. Customers want good software without knowing how to quantify good in software terms.
  - marcus_holmes 6y ago
    The purpose of commercial code is to make money. If the cost of annoyed customers is less than the cost of polishing the software, then the guy paying the salaries is right.
    - snarfy 6y ago
      In the short term. At some point you annoy your customers so much they get a Mac and never buy your software again. Compared to PCs, Macs are highly polished and just work (even if that's not entirely true today). Apple's success is a testament to the PC's lack of polish, the point being polish does matter.
      - marcus_holmes 6y ago
        I don't think this is true. I don't think people buy Macs because "they just work" - as you admit this is no longer the case and yet people still buy them. I run a Windows machine to play games on. I would dearly love to not run a Windows machine at all. But to play the games I want, I have to run a Windows machine. I'm not buying Windows because I love Windows and think it's amazing tech. I'm forced into buying Windows because the thing I want to do will only work on Windows. I'm forced to consider buying a macbook again, despite hating how closed the OS is and how dependent it forces me to be on Apple Support's weird shitty lying statements. I have to consider this because I will probably need to develop an iPhone app in the near future and I can't do that on a non-Apple machine. People buy tech to do things, not because they love the tech.
deleted 6y ago
[deleted]
pcstl 6y ago
I believe the author's point is that accepting that errors happen and that we need to deal with them - fail gracefully, as it were - produces more reliable systems than trying to obsessively eliminate every single point of failure.

by bezout 6y ago

CaptArmchair 6y ago

From the article: > Once you accept failure is inevitable and commit to avoiding the concatenation of failures that causes catastrophes, you—and your organization—need to decide what risk looks like and what to prioritize. If everything is the most important thing, then nothing is. [...] > The more complex the system, the more likely it is that some part of it is broken. As engineers, we’re at the apex of literally millions of hours of design and engineering time to help us, and our users, with everything from finding our phone to continuously integrating our code. We have to assume that some of that infrastructure, and some of our work, is broken. > If we accept these imperfections, we can work toward building resilient systems that can handle a little static and deal with flawed foundations without falling over. We don’t stop working toward perfection just because it’s impossible. The author's point isn't to throw up arms in defeat. Her point is to "courageously change the things you can change, accept the things you can't change, and find the wisdom to know the difference between the two". There will always be tension between striving for the ideal world where everything is always written to perfection using the latest innovative technology, and the real world where legacy code and technical debt are par for the course. It's all too easy to compare software on which lives depend (avionics, healthcare,...) with video games, short-lived marketing apps or business suites. "value for your money" means very different things to different people in different contexts.

MattPalmer1086 6y ago
I agree with your main point that the article is not suggesting giving up. It does amuse me though that an ideal of perfection is having no legacy code, all written with the latest technologies. I once spent some time refactoring some really old gnarly code to be beautiful and well designed. The rest of the team looked on in horror and asked why I was replacing highly reliable, battle tested code that had been in successful operation for nearly ten years!
- mgkimsal 6y ago
  > The rest of the team looked on in horror and asked why I was replacing highly reliable, battle tested code that had been in successful operation for nearly ten years! And they were probably correct in doing so. If people are expected to be making changes to it, but it's generally working well otherwise, adding explanatory docs, notes and tests around that code would likely be far more valuable than rewriting it. You have to understand the problem before rewriting anyway - writing up that documentation and supporting evidence is often a better goal than "rewrite" when a system is working pretty well in service. I've also seen the "don't rewrite it!" on code that is breaking/wrong constantly - like... daily. People have adjusted habits around it, and making a change is seen as 'risky' but there's a lot of unacknowledged operational debt that can be cleaned up with updating the code (investigate, doc beforehand too).
throwaway346434 6y ago
The tradgedy of flawed paid software is the people who pay, and the people who use it are often different. Accepting this after seeing it is equivalent to saying "I am okay with trading misery for profit". That bit isnt a software problem, but its not a good look!
mgkimsal 6y ago
> courageously change the things you can change, accept the things you can't change, and find the wisdom to know the difference between the two And trying to tell a client to 'accept the things they can not change'... doesn't often go over too well. Harder still in some cases because, technically, almost anything can be changed, but estimating the time/effort/cost is a difficult task in itself.
- afarrell 6y ago
  > doesn't often go over too well Beware the difference between being nice and being genuinely kind. The latter requires the courage to be willing to upset somebody and lose a lucrative contract.
  - CaptArmchair 6y ago
    It's true that anything can be changed. Improvement, however, is a form of value attribution. It's always in the eye of the beholder. It's totally valid to hold different ideas on how things ought to be improved. It's important to acknowledge that and bring that to the table. Even worse, compromising for the sole sake of signing a contract is a risky proposition. Projects fail because visions and ideas are being sold without acknowledging the reality represented in the limitations of existing technological solutions or infrastructure that needs to be maintained.

namelosw 6y ago

The customer of course desire high-quality product they have paid for. The problem is more often than not, the guy who pays developer salaries wants the developers to spend less time on polishing.

snarfy 6y ago
Very true, and the guy paying the salaries is wrong. The customers want the polish without knowing that's what they want. Customers want good software without knowing how to quantify good in software terms.
- marcus_holmes 6y ago
  The purpose of commercial code is to make money. If the cost of annoyed customers is less than the cost of polishing the software, then the guy paying the salaries is right.
  - snarfy 6y ago
    In the short term. At some point you annoy your customers so much they get a Mac and never buy your software again. Compared to PCs, Macs are highly polished and just work (even if that's not entirely true today). Apple's success is a testament to the PC's lack of polish, the point being polish does matter.
    - marcus_holmes 6y ago
      I don't think this is true. I don't think people buy Macs because "they just work" - as you admit this is no longer the case and yet people still buy them. I run a Windows machine to play games on. I would dearly love to not run a Windows machine at all. But to play the games I want, I have to run a Windows machine. I'm not buying Windows because I love Windows and think it's amazing tech. I'm forced into buying Windows because the thing I want to do will only work on Windows. I'm forced to consider buying a macbook again, despite hating how closed the OS is and how dependent it forces me to be on Apple Support's weird shitty lying statements. I have to consider this because I will probably need to develop an iPhone app in the near future and I can't do that on a non-Apple machine. People buy tech to do things, not because they love the tech.

deleted 6y ago

[deleted]

pcstl 6y ago

I believe the author's point is that accepting that errors happen and that we need to deal with them - fail gracefully, as it were - produces more reliable systems than trying to obsessively eliminate every single point of failure.