I'm Doing it Wrong? Really?

I chafe at how freely many of us will say you're doing it wrong.

Sometimes distinguishing a right way from a wrong way is easy. Sometimes it's not.

Holding a telephone handset upside down appears laughably wrong - unless you're doing a comedy bit (where it might appear laughably right).

The wrong way to produce software is not as obvious as holding a telephone handset upside down.

Producing software involves contextually-dependent variables. We are faced with business constraints, technical hurdles, and inter-personal challenges. Constraints, hurdles, and challenges are situationally-dependent. Constraints, hurdles, and challenges vary from product to product, and change from one environment to the next.

What might have seemed wildly right in one context, might be wildly wrong in another.

Your Dogma Ran Over Your Karma

A post was shared on agile .net practitioners with the title "If you are building applications without writing your tests first then you are doing it wrong. The title was probably meant to attract attention, and the post was probably written in the vein of self-promotion, but it got my attention.

I have benefited from the virtues of Test First, but the statement, "If you are building applications without writing your tests first then you are doing it wrong" seems hyperbolic, naive and unnecessarily dogmatic.

Situational Utility

Test-Driven Development (TDD) and Test-First have become catchphrases. Who hasn't been endorsed for TDD on their LinkedIn profile?

Several developers I know use Test First exclusively. Many more developers I know talk about Test First, but do Test After. Still more developers I know appreciate and espouse the virtues of Test-Driven Development, but rarely use it. Hardly anyone doesn't, at least, pay lip service to TDD.

Developers encounter many different situations. It follows that there are many ways to approach the tasks at hand. TDD is not the holy grail.

Craftsmanship Surcharge

There is at least one situation, and perhaps several more, where TDD or Test First adds a gratuitous craftsmanship surcharge to the bill.

Lets say you are contracted by a start-up to iterate from an initial proposition to a viable business model. Is TDD a cost-saving approach? Probably not. While the code might be flawless, TDD slows down the cycle of testing a business proposition thereby increasing the start-up's burn rate. Many start-ups don't need flawless code during the market testing phase. The reality is that there is going to be throw-away code, particularly in the context of a lean start-up where the team is meant to be in iterative learning mode.

Be Kind, Rewind

Several of the useful things many of us picked up in the early days of XP, and during the maturation of Agile, are too often applied as blunt instruments to pummel our less dogmatic teammates.

TDD can be a blunt instrument. Just like the common misapplication of Stand-ups, Retros, and Burn-down charts, Test First can degrade to an abrasive command-and-control directive as readily as it can prove to be a prudent practice.

The What and The Why

Approaches, practices and tools have a place when they serve The What and The Why. We agree craftsmanship deserves attention. As practitioners we love bullet-proof code. Many of us have gotten proficient at The How and The When.

I'm self-critical. I know I might be doing it wrong. In many cases, I presume to be wrong. But increasingly I don't care so much for The How or The When.

I'm reviving my old mantra: Don't Lose Sight of The What and The Why.