AddThis Social Bookmark Button

Listen Print Discuss
Mac OS X > Excerpts >

How to End Wars Between Testers and Programmers
Pages: 1, 2

Programming with Quality in Mind

Often, programmers and testers have very different ideas of what quality means. They're not alone. People have been arguing about quality for hundreds of years and haven't gotten very far (see Pirsig's Zen and the Art of Motorcycle Maintenance). The solution isn't in finding a specific answer for all time, which is impossible. Quality is highly subjective and means something different from project to project. Instead of seeking out a single answer, leaders have to drive for collective agreement on quality for the current project, and avoid philosophical debates.

Smart teams work on defining quality early. Since they know that towards the end of the project they'll need test cases to find bugs and evaluate progress, they decide not to wait to the end to sort those things out. Decisions about quality can be made early on.

Test-driven development (TDD), a popular approach for bringing quality into the process earlier, makes testing and quality assurance an integral part of every function and feature design. Before the code is written, test cases--conditions that the software must satisfy before it can be released--are created that define the conditions the code is to achieve. Just as you'd be foolish to start driving your car without knowing where you're going, why write code before you have a goal in mind? (Unless of course you enjoy wandering around highways and code bases.)

The spirit of TDD applies to all types of work. If you define the characteristics of the end results early, and communicate them to others, the odds of success always go up. It separates the ends from the means, freeing everyone to use whatever skills they have to help the project achieve its goals.

Only Leaders Start and End Wars

In the history of warfare, one thing is clear. It's those in power that create the conditions that lead to war. Whether it's acting out of fear or refusing to compromise, leaders have the power to start and end conflicts. Testers and programmers are no different. If there's strife in the programming trenches, look to the leaders for the causes.

The relationship between the most senior programmer and most senior tester sets the tone for the rest of the organization. If they ignore, ridicule, or patronize the other, others will follow. Leaders define a model for behavior--both in terms of how work in that role should be done and in how people in other roles should be treated. This also applies to group managers. The behavior of person managing all of the programmers and testers will define the rules of behavior for everyone else in the organization.

To improve on relationships between testers and programmers, the respective leaders need to take responsibility for the situation, prioritizing it well against more technical kinds of work. Forwarding articles like this one around can help bring light to the problems. But real improvement can only come when leaders step forward, openly acknowledge the problem, and bring people in from both sides to create a collaborative plan for how things must change.

Scott Berkun is the best selling author of The Myths of Innovation, and Making Things Happen. His work as a writer and public speaker have appeared in the The Washington Post, The New York Times, Wired Magazine, Fast Company, Forbes Magazine, and other media. His many popular essays and entertaining lectures can be found for free on his blog at Scott Berkun.

Return to the Mac DevCenter