It’s always a tradeoff

Leo Soto
Leo Soto
Aug 11, 2012 · 2 min read

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.

Leo’s Tech Blog

A personal blog on tech stuff.

Leo Soto

Written by

Leo Soto

CEO at ContinuumHQ.com, MITI.cl founder. Passionate software developer & MBA

Leo’s Tech Blog

A personal blog on tech stuff. Includes older entries that used to live on techblog.leosoto.com

Leo Soto

Written by

Leo Soto

CEO at ContinuumHQ.com, MITI.cl founder. Passionate software developer & MBA

Leo’s Tech Blog

A personal blog on tech stuff. Includes older entries that used to live on techblog.leosoto.com

Medium is an open platform where 170 million readers come to find insightful and dynamic thinking. Here, expert and undiscovered voices alike dive into the heart of any topic and bring new ideas to the surface. Learn more

Follow the writers, publications, and topics that matter to you, and you’ll see them on your homepage and in your inbox. Explore

If you have a story to tell, knowledge to share, or a perspective to offer — welcome home. It’s easy and free to post your thinking on any topic. Write on Medium

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store