1 million times this. And perhaps: does using the software make the user happy? Rituals and processes keep people in a job and sustain the agile industry, which is why they are being pushed everywhere.
They're signals that indicate a well-functioning development team, that can be researched with little effort and answered objectively.
"Does your software work?" is almost impossible to answer objectively, and doesn't help you determine if the software is going to work 2 years from now (which a good deal of development best practices work to achieve). You might as well replace the test with "Is this company awesome?"
In general, the way to objectively determine if software works is to give it to those pesky end users, have them use it, and tell you if it works or not, and how well it works. Lacking end users, have testers and QA folks who play the role of end users evaluate it.
In some areas of software development, such as heavy duty algorithmic/mathematical programs such as encryption, video compression, computer graphics, there are pretty rigorous objective ways to measure whether the program works and how well, without human testers or QA people. Usually best to do both even in these cases, just in case there are some subtle issues that the performance metrics don't capture.
On the other hand, predicting the future is noted for being rather hard. Predicting correctly whether a program will need to be changed in two years, in what way, and whether the program can in fact be changed easily all two years in the future is speculation, a matter of opinion, rarely objective at all.
You're right that there are classes of application that can be said to "work" objectively.
For the majority of business facing SaaS applications (to name an example), "working" is an elusive target. If we gave it to those pesky end users, and there's more than 5 of them, I guarantee you'd hear multiple answers to how well it works certainly, and even if it works.
I'm not saying that looking at how well your product works for people isn't a noble endeavour or anything. For the purpose of what this is supposed to be - an easily obtainable, objective measure of what it's like to work for a company, it's horrible.
Several of the points are effectively asking "Do you know that your software work right now?". Without CI and automated tests your knowledge of whether your software works is inherently limited in scope to what you can manually test in a reasonable amount of time and is out-of-date as soon as someone adds a new commit to master.
On the other hand, there are plenty of shops with CI and test suites that simply fail. Like, everyone knows lots of the tests are red from some legacy code or workaround, and they just stay that way at great length.
That's sort of my concern with these indirect questions about tools - it's very common to have them but not have them doing their job.
In my experience, good programmers can produce working software with or without any processes. Poor programmers cannot produce working software with even the most perfect, appropriate processes.
All of those practices can help, if used appropriately. But they're not going to magically make everything better.
Yep. There was good code before CI and source control, and there's bad code even where those things are in use. Certainly they're tools worth having, but checklisting tools doesn't actually say much about software quality.
The answer is universally the same across all software ever: no. The space shuttle probably came the closest, and they still had to fix bugs - or in other words there were still edge cases where the software did not work. You can step back from perfection, but then do you draw a line: even the most buggy software often worked a little in some situation.
If you have all of the list in software that doesn't work well I can spend the next 5 years fixing bugs and eventually get to useful working software - it won't be the most fun job but it won't be a job I hate. Everything you are missing from the list makes it that much more likely that the missing thing will frustrate me until I just want to quit.
If, in a complex domain, some metric gives the same result across the entire space, then there is a decent chance that the metric is not a very useful one.
Your stringent definition of "working software" seems to fall in this category.
Unfortunately, it's much more complex than that. Does your software work? Does your software work right? How quick you can add this to it? How to avoid bugs when you introduce complex change? How to share knowledge with new people in project?