If you substitute "practicality" wherever you see "worse is better", you'll have a much clearer idea of what the "philosophy" really is, and realize it in no wa

If you substitute "practicality" wherever you see "worse is better", you'll have a much clearer idea of what the "philosophy" really is, and realize it in no way conflicts with critical systems. All software design and development is done to a set of requirements. The more disastrous a failure would be, the stricter the requirements will be, and the more rigorous the processes will be. Like almost all other developers, my software does not run nuclear reactors, therefore I am not going to expend the resources to achieve the safety necessary for a nuclear reactor. It would be both unnecessary and economically infeasible. Do I care if a client makes a call to my IPTV webservice and gets back corrupt data? Well, yeah, but I'm not going to step through the entire software stack to mathematically prove it's impossible, nor am I going to encase the servers in a lightyear of lead to protect them from cosmic rays. I'm going to follow general best practices, let some testers play with it for a few days (while thousands of other lines of code in the client and server get exercised at the exact same time) and ship it. Why? Because the small risk of a user not being able to watch their favorite movie in some weird corner-case has less economic significance than me spending days making 100% sure everything is perfect in my new API call. At the same time, I recognize components of my systems that can have serious economic consequences, and accordingly invest more time in getting them closer to "right" (or avoiding them entirely -- e.g. not so long ago I ripped out all the C-style string/buffer handling from what was ostensibly a C++ library (not mine, originally) and replaced it with std::string and std::vector, which I knew were right, because people smarter than me had made sure they were, because everyone knew they had to be, and time was invested accordingly). This is a continuum, not a pigeonhole.