There are always circumstances when it’s inappropriate to apply a rule, but sometimes I find “pragmatism” is used as an excuse for not tackling difficult problems, or just not trying hard enough to find a solution.

Undoubtedly some practices are more difficult than others to learn. I find this usually with test-driven development (TDD) and pair programming, but also with things like sticking to work in progress limits if a team is running kanban.

This is often where I find “pragmatism” being used as the excuse. Developers won’t pair because their skills are mismatched. Or they won’t pair because their skills are well-matched. It’s not worth writing a test because the change is so small. Or because the change is too big. Or because it’s legacy code. Or… just because it seems very difficult.

For these reasons, even though I believe in pragmatism, my default is often to take a militant approach: everything must be test-driven, pairing is universal and mandatory. And if you find that’s a problem then don’t back out of it; let’s talk about it instead.

Writing automated tests around legacy code is often particularly difficult, but I will almost always help individuals work through it, and show them that what they thought was impossible or unreasonable is entirely within their grasp. Eventually, after attempting it again and again and again, they develop familiar techniques for tackling previously-impossible problems. Unless you actually do it you won’t learn. You can’t practice on the nursery slopes forever.

Similarly, I’ve worked with teams that were required to pair against their instincts. They’ve often found it difficult, and found it created problems (as well as recognising the advantages). But there are few real excuses. The problems have invariably forced them to think up ways of pairing that work for them: swapping at appropriate intervals, understanding the roles better, and so on.

In very rare cases we will have a conversation about something not being practical, and I will concede that that does indeed seem to be the case this time. But usually people can write automated tests and can pair much, much more than they think. It’s only after pushing the practices beyond those apparent limits can you really get a good understanding of where the limits of practicality are. This is when “pragmatism”—with quotes—becomes pragmatism—without.