Be a Quality Gate

There are two kinds of programmers: those who are pummeled by the software quality process and those who actively participate in it. Which kind are you?

Developers are often buffeted by the software quality process, floating and flailing in response to requirements and bug reports and deadlines. In order to make a difference in software quality, you the developer must become an active participant in the quality process instead of merely reacting to it. You need to become a quality gate, meaning you don’t take on work you can’t deliver on, and you don’t release code for testing until it is ready.

If a set of requirements is so poorly written, incomplete, vague, or full of contradictions that you can’t possibly develop reliable software for it, you must decline the requirement as insufficient. You can do this politely, gently, and constructively; simply point out what the problems are and ask for necessary improvements. Be open to iteration, and be open to partial stories that will be extended later, but do not agree to start work on something that cannot ever work properly. Similarly, you should also reject requirements that require skills you do not have, unless you and your management discuss it openly and decide this is a good opportunity for on-the-job learning of a new skill.

If your code is not known to be solid, you must withhold it from entering formal test. If your design is not clean, refine it. If your implementation is not complete, finish it. If your code is poorly structured, refactor it. If you haven’t sufficiently tested the code, test it. If you haven’t corrected all obvious bugs, fix them. Only then should you be releasing software for formal test.

It’s your enforcement of this that is critical. Developers who fail to hold the line on quality are like a piece of litter being blown around by the wind. If you aren’t already in the habit of pushing back when you need to, it’s time to learn this important skill. If it seems unpleasant, think how more unpleasant it is to have poor quality software out there and a damaged reputation—because that’s the alternative to a developer not holding the line on quality.

Please note, you can push back without being pushy! Be firm and candid, but not ugly or abrasive. Avoid seeming arrogant or uncooperative. Point out the very real consequences of not having a quality bar vs. the benefits of enforcing one. Express your concerns in a constructive, non-personal way, making it clear you are only interested in the success of the project. Be open-minded and listen to others in your discussions, and others will respond in kind. If you build a reputation as the developer with the greatest passion for quality and the most stable code, you’ll be astonished at the level of trust your team will put in you.

Right about now you may be wondering if doing all this diligent testing will slow you down to an unacceptable level; is the quality programmer destined to miss every deadline? Well, it’s certainly true that doing a job completely will take longer than doing a job minimally—so yes, there is going to be time impact. On the other hand, consider this: if your bug count is significantly lower than other developers, you’re not slower in the long term. In addition, as you develop better quality habits your improved code will require less debug time.

Be a quality gate. Do not accept flawed requirements that are so faulty they cannot be implemented, or that you lack the skills to implement. Do not release code for testing that has a questionable design, a weak implementation, or isn’t free of obvious bugs.

Advertisement

If we treated Programmers like Baseball Players…

What kind of developer are you, and what is your quality reputation? If we tracked programmers like baseball players, what would we see on your “programmer baseball card”? Let’s compare two developers side-by-side that way.

Joe is a young developer who is valued because JavaScript is his first programming language—unlike some of the older members of the team. Joe is very popular with management because he has a reputation for being fast: he is never late with his sprint assignments, and he’s written more lines of code than anyone on the team. However, are these the right things to be valuing? It’s revealing to take a deeper look at Joe’s stats. He has a very high count of bugs found by QA. Although he fixes bugs rapidly, the number of bug fixes rejected is very high. This tells us that Joe is “fast” because he is not really finishing his work completely. His bug fixes are often incomplete and are likely introducing additional bugs as well. Clearly, Joe has some good points but has a lot to learn about quality: his net quality contribution to the team appears to be negative.

In contrast, we have Sam who at first glance does not seem to do as well as Joe in some areas. He’s written far less code, he’s missed more meetings, and he often doesn’t finish his sprint tasks on time. Sam does need to improve his estimating and his attendance, but we can see from his other stats that these delays come from Sam’s commitment to finishing his work and testing it well. He has far fewer bugs than Joe, fixes nearly all of them, and his bug fix rejection rate is practically zero. Moreover, Sam’s statistics improve each year. This is why he has a reputation for quality. In light of this, we can see the reason Sam writes fewer lines of code: it does not indicate low productivity; rather, he takes the time to get his code clean, right, and nicely factored.

Determine the quality reputation you want to have and let that drive your behavior.