Software engineering vs other engineering

Quality Assurance (or QA) is a mechanism by which teams confirm that they’re hitting the requirements they’ve said they’d hit. One example is ensuring you’re validating your contractual obligations from a consulting standpoint. Another is making sure you meet the end user’s expectations.

A friend who does QA in the nuclear industry recently had some issues with an outside software vendor. They caused some political strife between the government and a native tribe because they didn’t follow the contractual processes. He wrote asking me if there were any similar standards to the “American Society of Mechanical Engineers QA Requirements for Nuclear Facilities Applications”, which outlines how teams build software in his industry. I didn’t have good news for him.

I wish I had better answers for you.

The truthful answer is that software development best practices could be best described as “goat rodeo”. There’s a lot of judgement used, and not much by way of formalized process. The bulk of this comes from a world where updates are free to ship, getting something wrong isn’t usually a big deal. The answers to this in particular are going to be coming up with a process and likely a checklist and lording some amount of power over them to ensure they follow it. You will likely be viewed as “impeding progress” or “making people’s life difficult”.

This industry is not a very mature industry. You’re effectively dealing with late-teens from a process perspective.

I might check into what the medical devices industry or NASA does. They are the ones with rigorous standards, but web people will balk at most of it.

Sorry I don’t have better news, -justin

Do you have questions about computer science or software engineering? I’d love to hear from you on twitter via email.