Quality Control, Quality Assurance
If you’re building software for a wristwatch in a sloppy way, who cares? Well, maybe the person who bought the wristwatch will care but they won’t die because their watch said it was 11:59 when it was really 10:30.
If you’re building software for a car or for financial systems or for medical equipment or for analysis on the effectiveness and safety of drugs, it’s critically important that the software be robust and works correctly at all times.
Building Software Right
To do that, companies must follow very strict quality assurance practices that are supported by the executive team. All over the world, strong support of effective ways to build safe software is weak to non-existent in many executive board rooms. Why? Because they’ve been trained (and rewarded) for different things — they’re financial experts or have their MBAs and deeply understand marketing but precious few really get behind what needs to be done to produce very safe, effective software that doesn’t kill people.
To be sure, not every company is slack on its software safety practices. But producing safe software is expensive and companies that care about this are put at a financial disadvantage because they must compete with companies that can produce sloppy software cheaply.
Software Safety Laws need to be put in place so that all companies that build critical software must apply the same rules.
Building New Software on Old Software
A great deal of today’s software is build on top of old, badly written software. That’s a problem because:
- Old software often has bugs lurking in it that get triggered by new software
Yes, very serious problems have happened because when the new software was layered on top of the old software, a defect in the old software that no one knew about had been waiting there silently and got triggered when the new software was layered over top of it.
How does that happen?
Imagine you’re someone with a bit of a weak back. You’ve lived with it all your life and not really noticed it bother you too much. Then one day, one of your children suddenly jumps on your back for a ride. Your back gives out. The problem with your back had been there all along but only got exasperated when a new situation appeared, when you were asked to carry someone on your back.
This is what happens with software. It can function just fine for years — decades — until something new shows up. The people who built the new software have no idea that the old software might have problems waiting to be triggered. Because it’s worked for so long, they expect it doesn’t.
Old software is often poorly built software
In the “old days” (70s, 80s and the wild 90s), there weren’t that many formal coding standards that everyone lived by. The assumption that they’re fine because they’re old is a dangerous assumption.
Car companies, financial institutions, and many other organizations build new software on top of old software. This isn’t a problem (for the public) if they’re building software for their own internal use. But when they build new software that’s supposed to work with the old stuff, and they don’t apply common software development safety standards, that’s when the problems appear.
Check back soon and we will put links to these serious situations here.