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.
Comments are Disabled