3 ms·

Is that so surprising? I have never worked in a domain like that, but I have always assumed that flight computer software would be built with process so deep th

by usrusr 7y ago

Is that so surprising? I have never worked in a domain like that, but I have always assumed that flight computer software would be built with process so deep that you could almost leave the implementation to trained monkeys, implying that those $9/h workers could still be overqualified. In my mental model of this kind of development (which could be wrong), you'd absolutely not want the 10x hotshot coder, you'd want predictable worker bees to faithfully transcribe from one specification format to another specification format slightly closer to the metal (or to a verification tool) until you eventually have a product that is working as designed. And from what I have read so far the MAX software does work as designed, the problem already started with garbage in. The article reads like an attempt at shifting blame that I think is entirely uncalled for.

salawat 7y ago
>In my mental model of this kind of development (which could be wrong), you'd absolutely not want the 10x hotshot coder, you'd want predictable worker bees to faithfully transcribe from one specification format to another specification format slightly closer to the metal (or to a verification tool) until you eventually have a product that is working as designed. Which gets you exactly what happened here. The 10x "hotshot coder" isn't a coder who vomits out 10x more code than another, but the coder that knows the right code for the job and also understands the provenance of from whence the data operated on comes from, and to whence it goes. Software engineering and computer science is about so much more than coding. It's about knowing the types of problems an implementation can solve, what boundary conditions have to be taken into account, and knowing what code isn't the right code. All for any subject matter area they end up operating in. You'll be amazed the speed ups you get from not having to write ten different versions of code implementing the same functionality before finding the one that plays well and reads well with the rest of the system. All that extra time spent not coding can be spent going over the operating environment to make sure the specification you were handed is actually complete. Unfortunately, I have the feeling Boeing would have hidden that information regardless seeing as their design doesn't even necessarily comply with 25.173 as written without interpreting it as allowing a computer to magically make an unairworthy frame airworthy. But that is beside the point. Once your management starts assuming the process will spit out product as high quality without your expertise, you can pretty much set up a timer to measure the time until the first impedance mismatch from a false assumption not rooted out rears its ugly head.
atpalmer 7y ago
Exactly what salawat said. The 10x coder isn't the "hotshot" type. They're 10x because they build systems well enough to deliver 10x the features, 10x the reliability, etc., etc. What isn't well understood is that software is never fully spec-ed out. No matter how hard some businesses may try, only the coder is in the position to find corner cases, unspecified cases, cases that "shouldn't happen" (but can), and just bugs in the spec. It's unrealistic to build a quality system without a feedback loop between the people writing the spec and the people coding the spec. Both sides have to be smart and engaged. There's certainly nothing wrong with the article. I didn't see it taking a point-of-view on who is and isn't to blame. It's telling factual information, which is relevant to the story of what happened, and you can make your own judgments.

by usrusr 7y ago

salawat 7y ago

>In my mental model of this kind of development (which could be wrong), you'd absolutely not want the 10x hotshot coder, you'd want predictable worker bees to faithfully transcribe from one specification format to another specification format slightly closer to the metal (or to a verification tool) until you eventually have a product that is working as designed. Which gets you exactly what happened here. The 10x "hotshot coder" isn't a coder who vomits out 10x more code than another, but the coder that knows the right code for the job and also understands the provenance of from whence the data operated on comes from, and to whence it goes. Software engineering and computer science is about so much more than coding. It's about knowing the types of problems an implementation can solve, what boundary conditions have to be taken into account, and knowing what code isn't the right code. All for any subject matter area they end up operating in. You'll be amazed the speed ups you get from not having to write ten different versions of code implementing the same functionality before finding the one that plays well and reads well with the rest of the system. All that extra time spent not coding can be spent going over the operating environment to make sure the specification you were handed is actually complete. Unfortunately, I have the feeling Boeing would have hidden that information regardless seeing as their design doesn't even necessarily comply with 25.173 as written without interpreting it as allowing a computer to magically make an unairworthy frame airworthy. But that is beside the point. Once your management starts assuming the process will spit out product as high quality without your expertise, you can pretty much set up a timer to measure the time until the first impedance mismatch from a false assumption not rooted out rears its ugly head.

atpalmer 7y ago

Exactly what salawat said. The 10x coder isn't the "hotshot" type. They're 10x because they build systems well enough to deliver 10x the features, 10x the reliability, etc., etc. What isn't well understood is that software is never fully spec-ed out. No matter how hard some businesses may try, only the coder is in the position to find corner cases, unspecified cases, cases that "shouldn't happen" (but can), and just bugs in the spec. It's unrealistic to build a quality system without a feedback loop between the people writing the spec and the people coding the spec. Both sides have to be smart and engaged. There's certainly nothing wrong with the article. I didn't see it taking a point-of-view on who is and isn't to blame. It's telling factual information, which is relevant to the story of what happened, and you can make your own judgments.