Respect, don't trust: A little philosophy on the emotional life of the software team.

I haven't heard much talk about the emotional world of the software engineer, so I'll offer some late night ruminations on the topic.

The deliberate conflict between the engineers making software and quality assurance fascinates me. Here's why: While software engineers passionately try to make things work, QA engineers diligently work to prove that the software is horrible. If you put this behavior in another context there would be pain and strife. One person persistently pointing out someone else's flaws. How rude!

In a healthy team, this is not discord, it is work and sometimes even fun. It's beautiful to watch. The graceful dialectic offers some life lessons and gives me hope in human nature. We can be honest and frank, we can seek truth and scorn "white lies". We can do this respectfully, with passion, and without hurt.

Here is how software teams make this work.

Respect, don't trust 

QA never trusts development. A QA who trusts the developer would believe -- without empirical proof -- that the software works. That would be silly. QA's role is to aggressively and skeptically to prove the developers' work flawed. QA seeks to prove. While mistrusting, the QA team respect the developers intelligence, creativity and passion. Respect does not require trust in this relationship - It a relationship where mistrust and skepticism are possible, emotionally, because of the teams' strong mutual respect. 

Trust and faith are good for your wife and your religion. Anyone or anything less than these gods deserves respectful skepticism. 

Be fearless of mistakes - mistakes and corrections make the world work. 

There are few situations in life where products must be right the first time. This is true in assembly line manufacture and live virtuoso performances. Most of life is about mistakes and corrections. In a conversation, if we don't understand each other, we dialog and correct. If I don't catch a fish on the first cast, I can try again. Bikes constantly wobble a little as we balance from side to side.  

Productive software engineers don't fear mistakes. Engineers who fear mistakes hoard their work for weeks, keeping it to themselves. Finally, pride satisfied, they throw an overwhelming amount of change of the wall to QA. QA needs weeks to validate - the cycles take many times longer than they should and the product is invariably late, rough in the places that need to be smooth, and polished in places where it doesn't matter.

Software works better when the developer fearlessly checks in small pieces of work continually. A little due diligence - send to to quality assurance. The right things are fixed and fast. Back to the physical world analogies: A bicycle with small wobbles moves fast. The only bike that does not wobble is probably smoothly falling over. 

Back to respect: The developer can fearlessly check in because of the respect offered from QA. QA respects the daring of the developer showing her raw work to the team.

( The final product is of course flawless. Mistakes the customer sees are bad. I'm talking about the early life of software. Typically, we make hundreds or thousands of bad builds before we make the final release build. So, the customer sees the one "right" build, but the life of software development is a story of continual mistakes and corrections. )

A defect in software is not a defect of the author.

Defect systems offer a powerful emotional tool - we don't talk about the systems this way very often. I rarely hear, in software, QA walk up to an engineer and say, "You stupid lout. You made the CSS wrong and the now the border of this table clips the text."

Instead, the developers does there best to make something pretty. QA digs into it, fines a tiny flaw, and files a bug report into a bug database. The bugs get prioritized, assigned out and fixed. The separation means that the flaw never gets personal. The author can handle a statement like "There is a flaw in the software" much better than "You broke the software."

All software teams think defect systems are essential for organization - I argue they are also essential to avoid getting distracted by the emotions of making mistakes.