managementGood programmers create fewer bugs while bad programmers cause more. Sounds logical, doesn’t it? However, there is a lot of criticism of this way of thinking. Take this one, for example: Bugs are inevitable, and instead of expecting fewer bugs from us, let us focus on the right design and let testers find and report bugs; then we’ll fix them. Or this one: Being afraid to make a mistake makes me write slower and experiment less, which translates into lower-quality software. Read more about that here and here. But allow me to look at this from a different perspective and assert that yes, indeed, good programmers create fewer bugs.
I think this is all about how we define quality and what a bug is.
If we look at a traditional and very “intuitive” definition of a bug, it is something that causes our software to produce an incorrect or unexpected result. However, if we think more about how the software is actually used and by whom, we’ll see that there are many other types of bugs, including scalability, reliability, and even maintainability ones.
If we put all those “-ilities” in a list and prioritize them by their severity and importance to the business, we’ll see that functionality-related bugs are rather far from the top. I would actually put maintainability at the top.
My point is that mistakes are not all equal. If I’m writing a PDF report generated by a piece of Java code and my report misses the footer, that’s one type of bug, and its fix will cost the business X dollars. On the other hand, if my PDF generation code is so difficult to modify that in order to change its format from A4 to US Letter we have to rewrite it from scratch, that’s a completely different type of bug. Needless to say, its fixing will be many times more expensive.
So yes, mistakes are inevitable. We should not be afraid of them and be ready to make them. However, good programmers make cheaper mistakes in order to avoid making more expensive ones.
Good programmers understand that in the limited amount of time we usually have to implement the software, we have to sacrifice functionality in order to gain maintainability. Ideally, you want to achieve both, but in reality, it’s next to impossible.
We all work under pressure, and we have time and money constraints. Within these constraints, good programmers prefer to make functionality buggy and incomplete while keeping the design clean and easy to maintain. There are exceptions, of course, where the business prioritizes functionality above everything else, but such situations happen very rarely (if the business is smart).
To summarize, I think that a good programmer makes more functional bugs than a bad programmer, though the bugs made by a bad programmer are more expensive than bugs made by a good programmer.
