I don't find anything in this list relevant (except maybe the natural language programming bit).
I think the most "uncomfortable" truth is the following:
* Bug-free/fault-free software is impossible
Although continuous/iterative development is very effective at minimizing the count and impact of bugs, but this is only relevant for web applications, and applications with some decent update system (e.g. Chrome, Apple's "App store", Ubuntu's PPAs, etc).
is a great line from the article that's still accurate. Small (simple) changes reduce the risk of using continuous deployment. Code should be modular and decoupled.
This is an absolute if you don't have the luxury of formal standards that stop evolving at a defined point in time.
It also means that you get to define 'bug-free' as 'implements the standard to the letter', not 'does what every single user expects all of the time, even when those expectations contradict and are insane.'
> It also means that you get to define 'bug-free' as 'implements the standard to the letter',
That doesn't make it any better. The standard itself cannot be bug-free.
Actually here's another one of them uncomfortable truths:
* You can't guarantee the correctness or reliability of a program by specifying on paper what it should do.
It's a bad approach anyway, and results in stupid programs; stupid in the sense that they will be hard to use, hard to maintain, hard to fix, hard to evolve, etc.
This truth maybe uncomfortable to many people, including bosses and managers and authority figures.
But, I personally actually find this truth very comfortable. Being the lazy slacker that I am, it allows me to justify my approach to programming.
> Formal systems will usually tell you when specs are outright contradictory.
Right, and I'm sure they're useful when designing avionics software. But how many web browsers have specifications, let alone specifications that can be subjected to that kind of analysis? Doesn't every user have a potentially self-contradictory and possibly insane 'specification' for 'web browser' in their head, and don't they think it's a bug when that 'specification' is not adhered to?
Maybe I should have just said there are two kinds of software: Software that is an implementation of a mostly-stable specification, like a POSIX-compliant OS or the aforementioned avionics software, and software for which no specification, or at least no stable specification, exists, such as web browsers and text editors.
I think the most "uncomfortable" truth is the following:
* Bug-free/fault-free software is impossible
Although continuous/iterative development is very effective at minimizing the count and impact of bugs, but this is only relevant for web applications, and applications with some decent update system (e.g. Chrome, Apple's "App store", Ubuntu's PPAs, etc).