Coder's conundrum | Datamation

Datamation content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.

Like any QA bigot, I can be critical of developers who seem to favor speed over quality when it comes to tracking bugs and testing during development. But, as in most cases, there are two sides to this story, and once you understand each perspective it makes the coder’s conundrum clear.

In a nutshell, programmers are not trained, scheduled, or rewarded for testing. Testing is not taught as part of the computer science curriculum–it’s a distinct discipline from both design and development. Schedules rarely allocate time for unit or integration test, and since problems are seldom tracked by developers, there is no reward for delivering well-tested code.

Coder’s conundrum unraveled

Create a culture that values quality by implementing a few simple changes.

Teach testing: Educate your coders about unit and integration testing.
Allocate testing time: Allow more time for developer testing–it’s worth it in the long run.
Track errors: Save time and rework by tracking who creates the bugs.
Monitor productivity: Don’t just measure developer productivity by lines of code, measure it by lines of error-free code.
Reward: Recognize and reward those who produce the cleanest code. Add quality objectives to their annual reviews.

“I’m measured by what I produce” in terms of lines of code, says a seasoned developer in a mutual funds company, “not by the number of bugs” in the code. “My schedules are always aggressive, so if I take extra time to test more thoroughly, I will be penalized.”

How does this happen? And, more importantly, what can you do about it?

Say what

Before we can expect developers to unit or integration test, we have to define what they are and explain it to them. Take the time to answer questions such as:

What constitutes a unit test? Where do integration tests begin and end?

Must each developer verify all classes of input and output, valid and invalid, as well as all error handling?

Is 100% coverage required? Is it reasonable?

Is it measured by lines of code, or must it include all possible pathways and states?

While it may not be practical to launch a full-scale developer’s education and training program, small steps can make a big difference. For example, one financial services company developed a simple unit test template that called for a list of each of the categories of input and output, the rule(s) that affected them, the selected test values, and the expected results. The developer completed the template for each unit, then–and this is key–it was reviewed by a cross-functional team of user representatives, QA staff, and development managers.

This basic process yielded many benefits. Incomplete or missing requirements were uncovered, thereby improving the programmer’s understanding. The test templates brought a consistency to the process and provided continuity to new developers whose task is to maintain existing code. Perhaps most importantly, quality increased and the cycle time to complete projects declined…but it wasn’t free.

Say when

The cost of better unit and integration test is, of course, time. Unless time is allocated and dedicated, testing won’t get done.

In the case above, the formalization of unit testing added about 12% to the development schedule but decreased overall cycle time by 30%. Why? Because the problems were found early, so they were easy to correct.

So if you expect your developers to do a credible testing job, allocate the time for them to do it.

Say thanks

I have always been bewildered by managers who refuse to track errors back to the individual developers. I know all the reasons–we don’t want to play the blame game, it will discourage developers from taking on complex tasks, it won’t reflect the variances in difficulty among modules, and so forth–but I don’t buy them. Ironically, testers often know who the culprits are, but their own managers usually don’t.

If you really believe that it’s cheaper and faster for developers to find problems than it is for testers or customers, then you should encourage them to do it. Measurement is a great motivator. Recognize and reward those who produce the cleanest code. Add quality objectives to their annual reviews. Create a culture that values quality.

While I don’t advocate the use of error counts to hold anyone up to scorn and ridicule, I do think they are excellent indicators of the need for training or discipline. At one global consulting company, for example, the test group for an outsourced application development project determined that almost 90% of the problems found during testing originated with a single programmer. Upon investigation it became clear that the individual had misrepresented his skills in order to receive, in effect, on-the-job training.

Whether the right decision is to remove the person or train him is not what’s important: what matters is that it’s the wrong decision to simply ignore the numbers and thus pay the penalty down the line in support and rework costs.

Say so

So instead of complaining about coders, come to their rescue. Help them help you. Teach them about testing, give them the time to do it, and reward them when they do. You’ll probably be surprised to discover that they’ll participate enthusiastically, since I’ve never met coders who didn’t take pride in their work…once they understood what it was. //

Linda Hayes is CEO of WorkSoft Inc. She was one of the founders of AutoTester. She can be reached at linda@worksoft.com.