Huffpost Technology
The Blog

Featuring fresh takes and real-time analysis from HuffPost's signature lineup of contributors

David Thielen Headshot

The One Big Thing That Will Reduce Software Bugs, But No One Does It

Posted: Updated:

This one simple change in the mindset of programmers can drastically reduce the number and seriousness of bugs. This change leads to software that works and is delivered on time. And yet, very few practice this approach.

This comes from the book No Bugs! (free downloadable copy here) which I wrote 25 years ago. And it's still spot-on today. The key to significantly reducing bugs in software is (from the book):

A developer I know once said, "Bugs should not be called bugs, they should be called Massive F#@k-Ups [MFUs]." "Bug" connotes that some outside agency decided to infest your program with bugs and that if you live a clean life, and sacrifice small furry animals at the foot of your computer, they will go away.

MFUs exist because programs are written by people, and people make mistakes. The only way to eliminate MFUs is to go into your code, find the bugs, and fix them.

This is the most critical concept to understand (and the one most often blown off). You will write MFUs. You will sit down and with complete malice of forethought put MFUs in your code. Think about it - you know that you are the one putting the bugs in there. So if you sit down to code, you will be inserting some bugs.

And somebody needs to find them so you can remove them. No amount of designing, prototyping, CASE, reviewing, management, and so on, will avoid this.

This concept is important because it colors your approach to debugging your code. If you view mistakes as "bugs," you hope none are found. (You hope the good fairy came by, sprinkled pixie dust, and the bugs left.) If you view the mistakes as MFUs, you know they unquestionably exist, and you hope to find all of them so that they can be fixed.

It's a simple but powerful change in mindset that has tremendous impact. But it's not easy to make this change. The resistance from most developers to this is strong because it means directly taking on the responsibility for the MFUs they inserted into the system.

Can you get your development team to take responsibility for adding MFUs to your code? If you can, the pay-off is gigantic.

From Our Partners