Tactical Solutions

"It's a tactical solution."

The tone was so dismissive. When did "tactical" become such a dirty word?

Software is rife with dogmatic pronouncements these days. BUFD is always bad. Unit tests are always good. Everyone knows that <insert-language-or-technique-of-your-choice-here> is better than anything else. Developers and coding are commodities. Process wins out over people; a good process can produce great code even when executed by average or below-average developers.

I personally hate dogma of all kinds. I recognize that accumulated wisdom needs to be respected. Physical laws are involate; I don't need to relearn lessons to keep fingers away from hot stoves. Gravity works. The second law of thermodynamics says that the egg I dropped on the floor might spontaneously reassemble itself before my eyes, but the probability is so small that it's never been observed. (But give it ten billion years and evolution could reconstitute it into something else, like a Boeing 737.)

Always relying on what everyone knows becomes a problem when context is ignored. Rules of thumb usually have exceptions, but the dispensers of dogma fail to bring them up or acknowledge them only grudgingly when they are pointed out.

There's also the question of who gets to decide what "everybody knows" when it's a non-scientific issue that's not entirely settled. History is full of people who have used dogma to serve their own ends. If the winners write history, it's also true that they decide questions of dogma.

I agree that slapping things together and being sloppy should not be anyone's goal in life. But prototyping something quickly, getting it out into the field, providing short-term value, and learning lessons from that experience has its place.

The objection to tactical solutions harbored by organizations is that they often become the de-facto standard solution, never to exit the portfolio again. This kind of organic growth can cause problems over time. But banning all tactical solutions feels like throwing the baby out with the bath. A better answer is to plan and budget for refactoring as needed. Retire those tactical solutions when the better, strategic thing comes along.

There's a tension between technology and economics. It doesn't pay to leap onto every new thing that comes along. The adoption curve for technology says that there are always leaders and laggards:

Organizations that are smaller, more nimble, and less risk averse get to be leaders and early adopters. If they play the game well they can get the jump on larger, slower, more conservative competitors. The larger competitors can leverage economies of scale and the damping that copious resources provide. They just need to be mindful of those tipping points that can shift the earth under their feet.

I wish that the timelines for payback were easier to quantify. Cost-benefit analysis can be made to come out to support the desired conclusion. Could Bayes and Monte Carlo be used to improve on what's done today? I'll have to think about that.

The truth is that everything is tactical. Technology is changing at a breathtaking rate. Every solution is tactical; they just have different timelines. (Just like there are no "permanent employees". We're all contractors.)

One final, funny thought: When I searched Google Image for 'tactical solution', I was surprised to see all the photos of weapons of all kinds. I had to scroll down several pages to find an image that expressed what I had in mind. The word is overloaded with military implications. It brings to mind SEAL squads and surgical strikes. That sounds effective when applied to certain problems. Why can't tactical software solutions be granted the same consideration when they apply?