Hacker News new | ask | show | jobs
by maxxxxx 3413 days ago
I don't do safety critical software myself but I work at a medical device company so I see the teams that work on patient facing products. Their cycles are much longer, management doesn't force new enterprise systems on them, they are very deliberate with changes. It's just a different paradigm. I didn't want to belittle the NASA guys but I just don't see much to learn from there. Their approach has the benefit of high quality with the trade off of slow pace of change.
1 comments

I agree. You get 90% of the quality for 10% of the cost by writing your requirements down, doing code reviews, and testing your programs thoroughly.

In fact, if quality is your main goal and you don't have to prove process compliance you can probably have a much safer product than the compliant competition by just investing the time spent on documenting every process step on writing better requirements, more tests, and refactoring your code to make testing easier. The last point is especially difficult in an environment where every software change needs a requirement.

Hah, the only thing that most people end up doing is code reviews and much of those are very relaxed and bare-bones.
A real thorough code review is a big deal. It probably takes as much time as writing it.