Eliminate Potential Bugs
If we really want to achieve software with an extremely low defect rate, it is not enough to react to software bugs and fix them after they have been introduced. One of the main principles of my style of software development is that we have to go on the offensive and eliminate or reduce the possibility of their creation.
Now this sounds like a good principle, but it is one of the hardest to achieve. It is hard to achieve because it fights the human desire to get quick results even if the results are not completely correct. We want to show something that works in most cases, but bugs often occur in the least used cases. Also if we tried to avoid every kind of potential bug out there we would probably never finish our task. So we want to find all the situations where avoiding an issue is more cost effective than dealing with the bugs that are caused by them. If you have ever spent a week, day or even an hour on a bug, you will realize how much extra code you could write to avoid the issue and still come out ahead.
Basically go through the kind of bugs that occur and ask yourself “How can I reduce creating this kind of bug again? Is it cost effective to do so?” After a while you will realize that additional code will often get you to a low defect rate sooner.
A probabilistic view of software development
For the majority of my life I have focused on becoming a better software engineer . I hope to share what I have learned to help other software engineers. Most of my career has been doing biomedical devices where software correctness is critical. By “correct” I mean bug free.
Unfortunately software development, even in the biomedical industry, has not achieved the maturity where we routinely prove our software correct. The current reality is that 99.99% bug free software without proving correctness is significantly cheaper than 100% bug free software by proving correctness.
So if we relax our bug free requirement how can we increase our chances of being correct? First we need to identify where bugs come from. It not like bugs are just random bit flips in binaries. A bug is is almost always due to an error in line of source code.
Now anybody who has programmed before knows the plethora of possible mistakes that can be made in a single line of code. You can use the wrong variable, misplace a comma, forget an prerequisite, forget to check an error state, off by one, memory leaks, etc. There are a nearly infinite ways of writing a line of code wrong. But after a while you will notice that there is not a equal distribution of mistakes made. You will notice that there certain kinds of mistakes in a line of source code that keep re-occurring.
Furthermore some kinds of bugs are more difficult to diagnose than other bugs. If we make the realization, that because we are human, we can not completely avoid mistakes in our software. I believe we can at least try to shift the kinds of bugs we have to ones we can more easily diagnose and fix.
So hopefully I will show you how to increase your productivity as a software engineer through knowing the trade offs you make in writing each line of code. A lot of these are considered best practices, but hopefully this probabilistic view of software development will help explain why they are good practices.
Recent Comments