Undeniable logic

One of the biggest mistakes I used to make in my career in the Industry was to think that a logic argument, well reasoned and with plenty of data to back it up was enough to convince reasonable and clever people, the kind of people I work with. An example is my favorite topic (no, it’s not commenting code), automated testing and unit testing: we all know that writing unit tests is a Good Thing™. We all do, right? There’s plenty of evidence and my argument for writing unit tests before even writing code is very solid. I was naturally expecting that after some resistance due to various reasons, the vast majority of my co-workers would eventually give up and embrace my reasoning, if not flat out try what I was advocating. But discussing automated testing here is not my goal now: my point is that very few people could actually see and understand my point. How frustrated I had been before realizing that it was all my fault.
It took years to understand that the undeniable logic in an argument is not enough to convince someone of its validity: it’s as important and most often even more important how the argument is expressed, how it’s told and explained.

John is a very clever programmer, extremely sure of himself, who likes to drill into the details of a problem; his method is tried and true, and he wants to give something else a go by himself before incorporating in his work. He likes to picture a problem and see a solution. I approach John and explain him that according to several studies writing Unit Testing  makes code more reliable and reduces cost of ownership for a code base, so he can focus on the general problem rather than fixing small bugs; doesn’t it sound correct? John thinks “bah” and moves on.
Trisha is a very clever programmer, who likes to keep herself informed by reading about how others in the Industry have solved similar problems in order to possibly produce something better for herself. She likes to think about the big picture rather than wasting time on irrelevant details. She wants to feel a problem before touching the right solution. I tell Trisha that if she tries Unit Testing for herself she will find that her code will be even more reliable, simpler and easy to change when she needs to change the details of the implementation, which is a result that she can immediately see after only few weeks. Trisha politely smiles at me thinking “bah” and moves on.
Things are not as simple as in my example, but we can immediately draw some interesting conclusions from it: in both cases what I told to John and Trisha is true and verifiable, but I failed to understand how they want information to be presented to them, which is radically different! John doesn’t care that others find Unit Testing useful, he wants to try for himself, while Trisha doesn’t want to try something if others haven’t already established it’s viable. John wants to see an argument not hear it, Trisha wants to feel it not see it.
Interestingly, addressing a group of people makes it even more difficult because different personalities are likely to be present, how about:

Writing unit tests before code is proved by different studies to be effective, which is something that you can see by yourself in just few weeks of trying it out, either on some small units or in a big problem that sounds difficult to tackle. You can easily feel the advantages or come to ask me for advice if you encounter problems.

How does it sound?
This realization makes leading a group of people even more challenging: now it’s important not only to have a solid and well thought-out vision, but also to understand the nature of the people we work with, how they want information to be presented to them, how they like to reason and respond to problems. Failing to communicate our vision is our mistake as leads.

Post also available on AltDevBlog.