Whatever works

This isn’t a movie review (though I highly recommend this 2009 Woody Allen film), but rather a reflection on its invitation to let go. Whatever Works, that title struck me at the time and has come back to my mind regularly over the past few years, so much so that I thought it would be interesting to explore its meaning in the context of product development.

Let’s not be more Catholic than the Pope

Discussions among developers tend to revolve around dogma. The battles between experts are the fiercest, even though they agree on 97% of the subject (but that remaining 3%, what a 3%!). Often, it’s really just a matter of definitions, so much so that, in practice, these people could actually see eye to eye. Example: Does Hexagonal Architecture aim to isolate domain logic or, more broadly, application logic? It all depends, of course, on what we mean by “domain.” And so a great deal of energy is wasted, energy that would be better spent discussing the matter with people who are far removed from what we generally agree to define as best practices in software development.

In fact, if just 50% of these practices were actually adopted by teams, we’d all be much better off.

A few examples:

• Test-Driven Development: all well and good, but it’s the gold standard. If there were already tests, even just unit tests written after development (Test After), that would be better than nothing and already a great deal.

• Another example: many of us recognize the merits of the Test Pyramid. But if a team prefers to write higher-level tests and that approach works over the long term, so much the better (and I’d be interested in taking a closer look to understand why it works).

• One final example: tests must be run by the continuous integration platform; that’s a given. But sometimes this is difficult, particularly for tests that require setting up a database. So, as a first step, running them locally before pushing the code changes already adds value and constitutes a step in its own right.

Pragmatism, please

This is a good opportunity to remind ourselves that best practices are numerous and well-established, but that most of the time they only make sense for specific use cases. Just one example: 100% of your codebase doesn’t have to be written using TDD; that would be falling prey to the infamous law of the instrument.

It’s not, then, a matter of scaling back our ambitions, but of being pragmatic and adapting to the situation: challenges vary depending on the business domain and the size of the teams. Best practices must be understood, questioned, and perhaps interpreted. Then, time should be our sole arbiter: if a team keeps up the pace over the long term and is satisfied with the work it produces, what more is there to say?

Ultimately, assuming we’re all trying to do the right thing, we can let go of some of that guilt. That was, in fact, the point of David Heinemeier Hansson’s rant in his article “TDD is dead. Long live testing”, DHH, whose excellent track record cannot be denied. I disagree with almost every position he takes in that article, but I truly understand how he feels. It would bother me if someone working with me felt that way, and I’d probably be willing to reevaluate my own positions to address it.

Doubt as a Driving Force

Beyond that, this “Whatever works” approach is a matter of doubt. And in saying that, we must distinguish between two types of situations:

• Situation 1: What you’re about to do is utter nonsense; you’re heading straight for the precipice. In such a situation, I’ll stand my ground for a while, regardless of my role within the team.

• Situation 2: I’m skeptical about the idea; I don’t see it working, but the risk isn’t huge, so go ahead and let’s revisit it soon—maintain a rapid feedback loop to make adjustments if necessary.

In this latter case, it would actually be interesting and even desirable to be wrong, because that would prove that my mental model of things no longer works and that, faced with this new situation, I need to adopt a broader, more comprehensive one that takes more parameters into account.

Doubt, therefore, encourages us to leave doors open. It may be uncomfortable, but it is a discomfort that drives progress, a discomfort that broadens horizons and allows us to go further.

This approach, of course, assumes agreement on a common goal: seeking what’s best for the product, the project, or the team. The goal isn’t to be right, but to find the best solution together, which is rarely a black-and-white position. It’s the art of nuance. And to achieve that, we must listen to the facts and defer to them.

I’m stating the obvious, but this requires mutual honesty and a desire to do things right that’s embedded in the corporate culture. Ultimately, if this framework is in place, if you’re discussing things with the goal of building a little more truth together, it means you’re talking as equals and that you’re a good fit for one another. This is a key criterion when it comes to hiring.

Doubt Makes Convictions Stronger

Don’t accuse me of relativism: the idea that everything is equally valid is one I abhor. Some things simply don’t work (letting your technical debt run rampant, for example); it’s proven and well-documented. But perhaps it’s precisely because you’ve had serious doubts that you’re able to vigorously defend a cause you believe in. Honest doubt is there to help you weigh the pros and cons: discussion after discussion, it becomes clear whether an idea holds up or not.