Worked on a codebase for a large safety-critical system where everything was 100% documented, and the development guide for the project was followed so closely that you couldn't tell, across millions of lines of code, that the whole thing wasn't written by one person. Absolutely impressive levels of attention to detail everywhere, down to not even being able to find typographical errors in comments or documentation (a typo in a comment was treated just as seriously as any other bug).
Not only was the funding effectively unlimited, but it was developed over 20+ years (so the whole program was designed to the standard that "the next person touching this code will never have touched this system before, and the last person who touched it isn't available to ask, and it still must be correct in the face of such change."
Nothing moved very quickly, sometimes a change request took a year from initial writeup to implementation and close-out. It wasn't creative, but it worked. Very well.
"When people thought the Earth was flat, they were wrong. When people thought the Earth was spherical, they were wrong. But if you think that thinking the Earth is spherical is just as wrong as thinking the Earth is flat, then your view is wronger than both of them put together."
I am almost sure this is because the system would have to pass a certification procedure somewhere, and for that they would need this level of clarity. Am I right?
Having worked in a couple of safety critical companies, there are things you definitely HAVE to do, but some companies do it better than others.
Some companies have process and development practices down pat: things go smoothly, and meeting the qualification process objectives is easy, because the work has been done right the whole way.
Other companies have less established or less consistent process. They generally meet the process objectives and deliver a working product, but the development process is often more of a struggle, and there is often a lot of "cleaning up" of missed pieces at the end of the release process.
This is just to say: companies and products in the safety critical space don't necessarily have some intrinsic quality, just a higher minimum bar.
In my experience there is exactly 0 correlation between certification needed and code Quality. Right now working in a multi billion company doing SW that must pass many certifications. The code is absolut trash. The tooling is terrible. The people confuse make and cmake. All said. And the SW gets certified, because it is all a matter of how much it costs to certify. It is a kind of high level corruption, that is not seen as corruption.
In my experience there is a correlation. All software I tested that had to be certified had the lowest quality by far. Certification only cared for the happy path and lots of very specific error messages. It was extremely important that the correct error codes were returned in the specified cases. Anything unexpected like e.g. an out-of-memory-error was more or less ignored because the specification didn't consider such kind of error. Even if it made the software unusable - all that mattered was the certification.
Having worked in both kinds personally, it's different.
You spend more time on less topics: the variety of work is much lower, which some people love, and some people are frustrated by. There is often much less "drastic innovation", or when there is, it takes much longer than you might be used to in other industries. Favor is given to proven, predictable technologies and choices, even if that leaves some opportunities on the table.
That being said, it's something I often miss. The ability to have such solid confidence on the things you've built, and the ability to drop into nearly any piece of the system and have everything be consistent and predictable is a quality in itself. It makes debugging (often VERY rare) issues much more tractable, both at a higher systems level, as well as digging deeper into the code itself.
Yep. Sometimes it's "known issues are avoidable issues", and other times it's "hey I wish we didn't spend xx% of our time avoiding (incl. spending time auditing syntax) or doing mitigations for the same limitations/issues over and over and over again".
