5 ms·

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

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).

n_ary 2y ago
Let me guess, it was very well funded and there were no fake deadlines and cross-team dependencies, am I correct or am I very correct?
- contingencies 2y ago
  Cancel the rocket launch people, we have a semantic incongruity! Correct is a binary state.
  - kridsdale3 2y ago
    Unless you're working with Quantum Correctness.
  - nurettin 2y ago
    If you allow for composable statements, the whole can be half correct.
  - Hasu 2y ago
    "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."
- f1shy 2y ago
  I bet you are very correct
- structural 2y ago
  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.
unboxedtype 2y ago
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?
- jamesmunns 2y ago
  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.
- f1shy 2y ago
  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.
  - unboxedtype 2y ago
    Sorry, I was talking about safety critical system certifications, like for avionics. The systems you describe would never pass that for sure.
    - oasisaimlessly 2y ago
      > The systems you describe would never pass that for sure. I wouldn't assume that.
rr808 2y ago
I'd love to know if working like this is enjoyable or a chore.
- simoncion 2y ago
  After way too many years of working on several sprawling Ruby and Rails projects, I would enjoy the everloving fuck out of working on this.
- jamesmunns 2y ago
  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.
  - noisy_boy 2y ago
    Sounds like a well maintained tractor from 1950s that is still chugging along.
  - Aeolun 2y ago
    > Favor is given to proven, predictable technologies and choices I feel like this goes two ways too. Sometimes people favor technologies they’ve used before, regardless of how many problems they know it causes. If it’s predictable that certain tech will cause you issues years down the line, do not choose it again.
    - jamesmunns 2y ago
      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". The wheels do turn, just slowly.

n_ary 2y ago

Let me guess, it was very well funded and there were no fake deadlines and cross-team dependencies, am I correct or am I very correct?

contingencies 2y ago
Cancel the rocket launch people, we have a semantic incongruity! Correct is a binary state.
- kridsdale3 2y ago
  Unless you're working with Quantum Correctness.
- nurettin 2y ago
  If you allow for composable statements, the whole can be half correct.
- Hasu 2y ago
  "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."
f1shy 2y ago
I bet you are very correct
structural 2y ago
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.

unboxedtype 2y ago

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?

jamesmunns 2y ago
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.
f1shy 2y ago
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.
- unboxedtype 2y ago
  Sorry, I was talking about safety critical system certifications, like for avionics. The systems you describe would never pass that for sure.
  - oasisaimlessly 2y ago
    > The systems you describe would never pass that for sure. I wouldn't assume that.

rr808 2y ago

I'd love to know if working like this is enjoyable or a chore.

simoncion 2y ago
After way too many years of working on several sprawling Ruby and Rails projects, I would enjoy the everloving fuck out of working on this.
jamesmunns 2y ago
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.
- noisy_boy 2y ago
  Sounds like a well maintained tractor from 1950s that is still chugging along.
- Aeolun 2y ago
  > Favor is given to proven, predictable technologies and choices I feel like this goes two ways too. Sometimes people favor technologies they’ve used before, regardless of how many problems they know it causes. If it’s predictable that certain tech will cause you issues years down the line, do not choose it again.
  - jamesmunns 2y ago
    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". The wheels do turn, just slowly.