Dan North has recently discussed the impact of opportunity costs in his article "The Art of Misdirection". Opportunity Cost is about choosing an obvious solution for a particular problem context, although sometimes an alternative option may be the better choice. Software engineers, in particular, are subject to such opportunity costs as they are constantly facing decisions in their daily work.
Dan claims, software engineers are always in danger of opportunistic costs. To prove his point, he is suggesting the following exercise:
Try this two-part exercise: Think of a practice or technique you use when you develop software, maybe your favorite practice. Got it? Ok, part 1: why do you do it? What benefits does it give you? You can probably think of a few. Write them down. Now, part 2: where wouldn’t you use it, and what are some alternatives? Write down some pros and cons of each one
As an example, Dan uses TDD (Test-Driven Development) which he considers "among the most dogmatically advocated practices I’ve encountered."
According to Dan, the opportunity costs by TDD capability could be caused by the desire for steady and confident change, emergent design, automated tests, and tests as living documentation. For example, in the domain of financial trading applications it could be useful to try several sketches without applying TDD which would incur too high cost and time penalties. Regarding emergent design, TDD is like searching for local maxima, while finding the best solution may require a more radical rethink. And using tests as living documentation might lead to a lot of unnecessary noise.
Dan concludes his article with the following recommendation:
So take nothing at face value, and instead look for the trade-offs in every decision you make, because those trade-offs are there whether or not you see them. And if you can learn to spot them you can do magic.
Some readers agree to Dan’s arguments. Gene Hughson explains,
Excellent article. Adopting anything, whether technology or technique, without adequate thought about the costs as well as the benefits, is a recipe for disaster.
However, other readers have a different opinion. For example, Sam Weisen claims in his comment that the article gave TDD a rather unfair treatment:
You have, I’m afraid, misunderstood TDD Your assault on TDD is vacuous. You probably have some point to make in there, but it’s lost in the tirade.
Liz Keogh supports the points made in the article and suggests, some believers in Agile Development should be more open to other opinions:
I can see a few people in these comments who’ve fallen prey to the “No True Scotsman” fallacy; that if something isn’t working for someone, that person must be doing it wrong. It’s a sentiment I’ve seen on a few Agile blogs, too, particularly around TDD but also Scrum. There are so many contexts, from rolling out a timesheet app to fixing an urgent production bug, where TDD simply isn’t appropriate, and many too where TDD is a good practice, but not amongst the best.
While not everyone might be in favor of Dan’s points, especially regarding to TDD, it should be considered as an opportunity to take another perspective. As Justin puts it,
Thanks for calling our attention to these blind spots: All this article is doing is forcing you to go outside of your comfort zone and challenge what you think. I’m sure many successful teams take bits and pieces from all of these methods and put them together to make a productive team.
