> Maybe the author doesn't remember the blue screen of death, or reflexively hitting ctrl-S every five minutes to save because the software might crash, or clic

> Maybe the author doesn't remember the blue screen of death, or reflexively hitting ctrl-S every five minutes to save because the software might crash, or clicking on menus in Word and they wouldn't open because you had a macro virus. That was my first thought too. My second thought was that was 30 years ago. Different people may be using a different era as a reference. When it comes to software reliability, the industry appears to go through a push every once in a while. In the mid-1990's there was a push to introduce memory protection into personal computer operating systems. Software became more reliable because it was protected from other software, and because it became more difficult for software to trash the operating system's memory. In the early 2000's security was a much greater issue, so we saw another push that affected software quality. Well, several pushes. So yes, there has been a definite improvement in software reliability in some respects. Yet software reliability is also about the people sitting behind the keyboard and writing the code. Better operating systems and better development tools may help to catch some of their errors, but it won't catch all of their errors. If they try to (recursively) calculate the Fibonacci Sequence with `f(n-1) + f(n-1)`, the computer will gladly do it and gladly produce the wrong result. Of course development tools aren't infallible either, and what they catch depends not only upon which tools you use but how you use them. For example: C won't detect integer overflow. Rust appears to be somewhat better. It will detect overflows in debug builds, though it will only not detect overflows by default in release builds. It also offers functions to handle overflows in various way. But as soon as you depend upon a developer changing a default or making an explicit function all, you are bumping into the same issue as the Fibonacci Sequence example: the computer is going to gladly do what the developer told it to, even if it is not correct. Even though software reliability is tremendously better than it was 30 years ago because of technical improvements in the operating system and development tools, I suspect it also ebbs and flows on shorter time scales simply because there are entire classes of errors that are affected by the people who develop (or fund the development of) software. (Edit: in a twist of irony, HN was not responding when I initially tried to post this. Another point is that the reliability of a lot of modern software depends upon external services.)