Reductio ad Absurdum

January 24, 2011 by
Filed under: Process, Quality, Teamwork 

I got a note recently from someone halfway across the world, asking about a detail in my white paper about quantifying the quality requirements of a system. The query me ponder for a moment before I came up with a reasonable response, but I think it highlighted something that applies in a broader sense as well.

The question was about one step of the process where we take a list of potential quality attributes and prioritize them for the particular project in question: is safety more important than interoperability, for example. The approach calls for a pairwise comparison of each of these, and the total of the ‘wins’ sets the overall priority list. In particular, this person was concerned about the possibility of transitive inconsistencies, where a>b and b>c and c>a (think, for example, a situation where usability is seen as more important than security, which is seen as more important than testability, which is seen as more important than usability). If our approach is to look at each pair in turn, this inconsistency could happen, though I have rarely seen it in practice

Indeed, this person suggested that once we have looked at the first two pairs and come to some relationship, then the third one could potentially be resolved automatically, and simplify the whole process.

Yes, this could be done, but I think this reductionist approach goes too far.

In the case above, the point of the exercise is not to have an absolute ordered list of the different quality attributes of the system, but to use the approach as a means of exploring different stakeholder perspectives to arrive at a shared reasonable solution. The goal here is to get these diverse viewpoints out on the table, not to arrive at a precise conclusion as quickly as possible. I can live with any transitive inconsistencies in our discussion far more than I can live with critical viewpoints never being raised in the name of expediency.

If anything (upon further consideration), exposing these transitive inconsistencies could allow us to identify potential areas for deeper discussion, rather than avoiding them with short cuts.

In a more general sense, I believe we try a reductionist approach too often, too early in the game.

When we think about how we are going to complete a project, many people seek an ‘a priori’ straightforward approach. Most organizations strive for a defined approach to their projects even before they know the nature of their next project.

Indeed, there is a great deal of allure in that holy grail: a clear, simple set of practices that will allow us to drop a problem into one end, turn the crank, and reliably come out with a satisfactory solution at the other end.

Almost everyone that has come through the PM Certificate program I mentored over the last three years started out looking for this recipe for project success. Similarly, there are plenty of consultants doing quite well selling snake oil in the form of a simple, repeatable approach, some even suggesting it is generally applicable.

If you have flour and water and a pinch of yeast and salt, you can make a kick-ass loaf of bread. If you have some hops and maybe some other starch as well, you can complement the bread with some beer. Life is good. Very simple, and straightforward (with a little practice). You can consistently make those loaves of bread, and consistently have some ale to wash it down.

But this is far from generally applicable. You won’t get close to a pasta primavera or a smoked salmon pate, or a key lime pie, even though those basic components contribute to the solution. What we need to be able to solve a more general problem of ‘I’m hungry for something different’ is a well stocked pantry.

So it goes with projects. Projects come in all shapes and sizes, and different tools need to be applied in different situations. Team cultures vary tremendously, environmental pressures exert different strains on the team, the only thing consistent between all projects, even in a single shop, is their wide variability. To ever suggest a single, unified, straightforward approach is lunacy, yet we continue to seek it out.

Solving a wide range of problems will necessarily require the application of grey matter, and the project equivalent of that well stocked pantry. We need a wide range of tools that we could apply if the situation warranted, which means we need to understand how and when to use them, and how they interact with one another.

One of the values of having a widely diverse team is that each can bring expertise in complementary tools, so that no one person needs to be the jack of all trades. Another value is the different perspectives that can be brought to bear on the problem, and the last thing we want to do on a project is to try to replace the conversations with a reductionist solution that simply provides an answer quickly. Sometimes the right answer will only come with time. – JB


One Response to “Reductio ad Absurdum”

  1. Venkat Moncompu on December 16th, 2011 10:03 am

    Awesome post. I cannot see anyone writing in a more articulate manner than you’ve done regarding the multifaceted aspect to software quality.


Feel free to leave a comment...

  • What’s Happening

  • On The Road Again

    Jim frequently travels across Western Canada for engagements, and welcomes opportunities to meet, run a workshop, Diagnostic or Lunch and Learn session.

    Contact Jim if you would like to connect around any of the upcoming dates:

    • Blissfully at home in Vancouver, BC over the summer!
  • What People are Saying

    Jim is simply one of the smartest and most knowledgeable software development professionals I have ever met. His vast knowledge of the discipline is both leavened and enhanced by his acute awareness of and sensitivity to “the real world” of what actually occurs with real developers in actual practice. Jim is also a warm, open, honest person – rare gifts and an asset in any consultant.

    — Bonar Harris