Thanks for writing this (just a generally interesting window into a rare industry). As you point out, you can't only ever add. If there was a study suggesting that static types don't add enough safety to justify tradeoffs, you might consider phasing them out. In your industry, they are currently acceptable, there's consensus on their value. You probably have to prioritize procedure over individual developers' clarity of perception (because people differ too much and stakes are too high). That's fair, but also a rare requirement. Stakes are usually lower.
> If there was a study suggesting that static types don't add enough safety to justify tradeoffs, you might consider phasing them out.
Perhaps. Speaking personally now (instead of trying to generalize for the industry), I feel like almost all of the success stories about increasing code quality per unit time have been stories about putting defect detection and/or elimination left in the development process -- that is, towards more and deeper static analysis of both requirements and code. (The standout exception to this in my mind is the adoption of automatic HIL testing, which one can twist as moving testing activity left a bit, but really stands alone as adding an activity that massively reduced manual testing effort.) The only thing that I can see removing static types is formal proofs over value sets (which, of course, can be construed as types) giving more confidence up front, at the cost of more developer effort to provide the proofs (and write the code in a way amenable to proving) than simple type proofs do.
The most important ingredient by far is competent people. Those people will then probably introduce some static analysis to find problems earlier and easier. But static analysis can never fix the wrong architecture and fix the wrong vision.
In the industries I've worked, it's not a huge problem if you have a bug. It's a problem if you can't iterate quickly, try out different approaches quickly, bring results quickly. A few bugs are acceptable as long as they can be fixed.
I've even worked at a medical device startup for a bit and it wasn't different, other than at some point there need to happen some ISO compliance things. But the important thing is to get something off the ground in the first place.
> The most important ingredient by far is competent people.
Having competent people is a huge time (cost) savings. But if you don't have a process that avoids shipping software even when people make mistakes (or are just bad engineers), you don't have a process that maintains quality. A bad enough team with good processes will cause a project to fail by infinite delays, but that's a minor failure mode compared to shipping bad software. People are human, mostly, and if your quality process depends on competence (or worse, on perfection), you'll eventually slip.
Right, but I hope you also understand that nobody's arguing for removing static types in your situation. In a highly fluid, multiple deployment per day, low stakes environment, I'd rather push a fix than subject the entire development process to the extra overhead of static types. That's gotta be at least 80% of all software.
