I always regarded Computer Engineering as the inferior form of engineering. My inflated ego and arrogance never interfered with this.
Mechanical engineers chewed differential equations and physics. There I was with propositional logic.
But most prominently, software was always excused for having bugs. Even assumed to have them. "All good, the authors mostly provide a quick resolution".
I compared our software creations with skyscrapers, bridges and heavy machinery. There was not much room for doubt: those were the majestic endeavors. We are the ugly ducklings. Useful -- sure -- but clumsy and unserious.
I had no problem with that belief. The generous hourly rates I received as a 20 year old IT consultant surely helped.
Towards the end of my studies I ran into these words by the world's top cybersecurity expert:
If we expect companies to spend significant resources on security -- especially the security of their customers -- the security vendor must be liable for security mishap. If we expect product vendors to market secure products, they must be liable for security vulnerabilities in their products. Liability is an essential component of an environment that fosters security.
-- Beyond Fear, Bruce Schneier (2003)
They spoke to my heart. “That was the way!” -- I thought. Liability could cleanse the profession from clumsiness and finally make space a reputation.
A moment later I reasoned on. How unlikely is this shift, really? We're far from it. No supplier has an interest in that. No client has power to demand it. "It's delusional!”.
But Bruce soon continued:
One of the interesting effects is the rise of the insurance industry as a facilitator of increased security. In many areas of our society, the insurance industry drives security. A company doesn't by security equipment ... just because it want to feel safe. It buys that security because then its insurance rates go down.
Beautiful. Hard. But economically feasible. I was persuaded. This is the way I wished the profession to tick with. For ourselves and the benefit of society.
20 years on we're a bit further. Systematic Testing is prevalent. Test automation is so commonplace that DevOps engineers ensued as a profession. One in high demand, too. We are on the right path -- just somewhat slow.
Most companies today do systematic testing for cost control. Avoid the fuss and commotion of patching 0-days and critical bugs. But how well do they?
That's where we have large room for improvement. There's a feeling that “some” coverage is “enough”. Avionics software regulations mandate complete coverage of various forms. Meanwhile the rest of the industry settles for symbolic values. 60, 70, 80%. Reaching 90% is for "exemplary" companies.
But 90% leaves a lot of code out. What's with that code? Here's some questions:
- if you have a line of code in your software, why should it not be tested?
- Is the feature behind it not that important?
- If it is not, why does the feature need to be in?
- As you don't know if that feature works or not -- what's the risk if your users actually use that feature?
- What's the risk of removing that line of code?
- What's the benefit of removing it?
Reason through these questions. In most cases, you'll end up adding test cases for it. If you don't, try removing that code.
It'll be difficult. You'll be afraid. But it'll stay in your repo history, so you're always able to bring it back if you need to.
Most often, you won't. You won't even remember of it. And if you will bring it back, you'll write test cases for it.
That applies to commercial software and open-source as well. If you build something, you'll offer people functionality that they will depend on.
I recently open-sourced Tattler. It helps online services do email and SMS notifications. During its development I set 98% as the target statement coverage. That only left testing-specific lines out.
Coding test cases takes roughly 50% of the development effort. They also keep me much more disciplined with the features I introduce. “Is this error case really possible? Do I want to rely on this feature?”. The resulting leanness and consistency feels great.
That does not prevent the software from having occasional glitches. And that's the thing. It's a nightmare to think how much firefighting work it'd take if those test cases weren't there.
Top comments (0)