# Good Programmers Write Bug-Free Code, Don't They?

Source: https://www.yegor256.com/2015/06/18/good-programmers-bug-free.html

Good programmers create fewer
[bugs]({% pst 2015/jun/2015-06-11-wikipedia-bug-definition %})
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](http://programmers.stackexchange.com/questions/41248) and
[here](https://www.joelonsoftware.com/articles/fog0000000067.html).
But allow me to look at this from a different perspective and assert
that yes, indeed, good programmers create _fewer_ bugs.


{% jb_picture_body %}

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]({% pst 2014/oct/2014-10-26-hacker-vs-programmer-mentality %})
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](https://en.wikipedia.org/wiki/Paper_size) to
[US Letter](https://en.wikipedia.org/wiki/Letter_%28paper_size%29) 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.

{% quote Good programmers make cheaper mistakes in order to avoid making more expensive ones %}

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.