It’s always a tradeoff

Posted by Leo Soto on August 11th, 2012.

I started my professional life in a company where I was the main force pushing for unit testing. Years later I worked in a company where TDD and Pair programming was the strict norm. Today I work in Continuum where we occasionally practice pair programming and TDD.

As expected, I am one of the advocates for doing more testing inside Continuum. But one thing I am not is to be dogmatic about it. I strongly believe that testing is worth it, and in many cases believe that testing first can be a good idea. In particular, TDD coupled with pair-programming is sensible as it keeps the team in the same page all the time.

Anyway, the point I am trying to make in the paragraph above is that I am mostly pragmatic on my beliefs of the usefulness of testing. I believe it is mostly context-dependent. In other words: automated testing it is a trade-off. One which usually works, but a trade-off nonetheless.

I hate how things in the software practice usually go from “trade-off that usually works” to “rule of thumb” to “dogma that you better practice unless you are not really professional”. The most dangerous transition is the first one though: As soon as the awareness that a tradeoff exists is removed, it becomes a matter of “us versus them”. The “pair programmers” vs “solo programmers”. The “real agile” vs “undisciplined agile”. And so on.

Which is stupid, as reality will punch us all in the face eventually. For example:

“the research team found was that the TDD teams produced code that was 60 to 90 percent better in terms of defect density than non-TDD teams. They also discovered that TDD teams took longer to complete their projects — 15 to 35 percent longer”

— Exploding Software-Engineering Myths, Microsoft Research

(By the way, go and read that full article if you have time. It is really, really interesting)

I would expect to hear similar results if any empirical study has ben done for pair programming in terms of quality gains at the expense of more cost. Knowing those tradeoffs your team can make a judgement call in a project by project basis (and, more realistically, feature by feature basis), to fine tune the application of these practices to the reality of our context (project, client, development team, etc, etc). For that to happen, we first must realize and keep in mind what’s behind most practices, algorithms and techniques in computer science and software engineering:

It’s always a tradeoff.

Originally published at techblog.leosoto.com on August 11, 2012.