Being Pragmatic about Bugs
Published Wednesday, August 11, 2010 by Torbjörn Kalin
Tags: kaizen, pragmatic, programming, quality, tdd
In my Curriculum Vitae I have written that I value organisations that don't bargain with quality. In the same CV I have written that I consider myself to be pragmatic.
A few year ago I went to an interview where they asked me how I could consider myself to be pragmatic and at the same time not be willing to sacrifice quality. Appearently, they considered that to be a contradiction.
I later learned that the product that the job opening was for was a 100 KLOC application that had hundreds of bugs. And this was after the team had spent the last three months doing nothing but bug fixing. Oh, and the team did very little testing, so these hundreds of bugs might only have been the tip of an ice berg.
I wonder, is that being pragmatic?
I guess few people would say it is. For apparent reasons, having hundreds of bugs in quite a small application can't be a good trade-off.
But what do I mean then when I say that I don't want to bargain with quality? How many bugs can you have and not bargain with quality?
The short answer is: zero bugs.
But that can't be pragmatic, right? It sounds more like dogmatism, doesn't it?
Which leads me to my long answer.
If you use the same practices trying to reach zero bugs as the organisation I mentioned above, then you will fail. You will fail because you will do nothing but bug fixing. You will spend most of your time in front of a debugger.
Bugs are a part of their system. They expect them. They are waiting for them. It's a natural thing to have bugs, and they can't imagine a world without them.
And herein lies the problem. The problem is that the organization does not try to improve. They don't try to learn.
A bug is an opportunity to learn. And not seizing the opportunity to learn is a failure. That is, a bug is only a failure if you don't learn anything from it. And to reach zero bugs you have to seize every opporunity you get.
If, for every bug you discover, you try to figure out a way to prevent the same bug, or even better, the same kind of bug from ever happening again, then and only then do you have the chance to reach zero bugs.
That is, you need to change your practices from being reactive towards being more proactive.
A few year ago I went to an interview where they asked me how I could consider myself to be pragmatic and at the same time not be willing to sacrifice quality. Appearently, they considered that to be a contradiction.
I later learned that the product that the job opening was for was a 100 KLOC application that had hundreds of bugs. And this was after the team had spent the last three months doing nothing but bug fixing. Oh, and the team did very little testing, so these hundreds of bugs might only have been the tip of an ice berg.
I wonder, is that being pragmatic?
I guess few people would say it is. For apparent reasons, having hundreds of bugs in quite a small application can't be a good trade-off.
But what do I mean then when I say that I don't want to bargain with quality? How many bugs can you have and not bargain with quality?
The short answer is: zero bugs.
But that can't be pragmatic, right? It sounds more like dogmatism, doesn't it?
Which leads me to my long answer.
If you use the same practices trying to reach zero bugs as the organisation I mentioned above, then you will fail. You will fail because you will do nothing but bug fixing. You will spend most of your time in front of a debugger.
Bugs are a part of their system. They expect them. They are waiting for them. It's a natural thing to have bugs, and they can't imagine a world without them.
And herein lies the problem. The problem is that the organization does not try to improve. They don't try to learn.
A bug is an opportunity to learn. And not seizing the opportunity to learn is a failure. That is, a bug is only a failure if you don't learn anything from it. And to reach zero bugs you have to seize every opporunity you get.
If, for every bug you discover, you try to figure out a way to prevent the same bug, or even better, the same kind of bug from ever happening again, then and only then do you have the chance to reach zero bugs.
That is, you need to change your practices from being reactive towards being more proactive.
No comments:
Post a Comment