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.