Defects in software have always been and will always be a subject of interest. And it’s not just software. Every industry is obsessed in some way with defects.
Software development has evolved a plethora of techniques to identify and eliminate defects. Practices to find out about defects quickly. And practices to hopefully avoid introducing defects.
Unfortunately many of the practices and techniques are reactive. They’re about catching the problem after the fact. For example monitoring a system for exceptional behavior. Some of the techniques are proactive too. For example continuous integration to mitigate people stepping on each other’s toes.
But even with an overabundance of means to deal with defects, they still happen. They’re still the subject of much interest. And that’s because we haven’t spent enough time talking about the real cause of defects. We’ve only been dealing with the aftermath.
The primary cause of defects in software is building software that shouldn’t be built in the first place. The value of the software is poorly understood. The purpose is unclear. There’s no way for it to be built right because there’s no way to build the wrong thing the right way. There’s no purpose so there’s no way to really validate it does what it should do. As such it’s anyone’s guess as to what it should do because the best that can be done is to build the software to one’s understanding of technical specifications. There’s no purpose beyond specifications to validate.
Even if it could be validated, there’s no justification to spend the money necessary to validate it. To invest the time in validating it. There’s only enough money to do a hack of a job to get it out the door. To throw something together and see what happens.
It’s not uncommon for systems to be bloated with significant amounts of this garbage. Piles of functionality that may or may not do what someone at one time thought it might need to do. Piles of software that clogs the arteries of valuable functionality. Piles of functionality that most people aren’t even aware of because it serves them no purpose.
On the flip side, when software serves a valuable purpose, the priority and support will be there to make sure it works. To make sure it serves a valuable purpose. And to make sure it fulfills that purpose. All the testing necessary won’t be an issue. All the review necessary won’t be an issue. The specifications will be irrelevant so long as the goal is met.
Why does this happen? Because the entire industry of software development has become obsessed with the technical specifications and efforts involved in software development. Developers aren’t treated as engineers, they’re a set of hands to carry out someone else’s decision. The software is treated as an end, when it should be a means to an end that’s valuable to the business.
This obsession over specifications leads to an investment mentality of doing as little as possible just to see what happens. Because nobody has the information in advance to figure out the effort isn’t worthwhile in the first place. Effort after effort fails, so people are rushed to try lots of things hoping one will stick. Hoping one of their many attempts will somehow be valuable to someone five levels above their pay grade.
If a team can focus on results, they can then minimize what must be done. They’ll cut out the majority of the software they might have otherwise had to create. And naturally the surface area for defects will fall exponentially. For the work they have to do, they’ll have the priority, support and focus necessary to make it work like a well oiled machine.
So if you want to eliminate software defects, stop building functionality that shouldn’t exist. Any other possible defect will pale in comparison and will be a pleasure to fix because it serves a laudable cause.