3 ms·

From the article: > Once you accept failure is inevitable and commit to avoiding the concatenation of failures that causes catastrophes, you—and your organizat

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.

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.