I spent quite a bit of my early career learning pragmatism. Frankly I did not know the word until I entered the industry. ;). I got this as a feedback, quite a few times, from my colleagues and more so from clients. They would say “You need to be more pragmatic”. What that really meant is, stop being so obsessed with you software engineering “craft” (my clients didn’t even think it was craft :)). Its ok to not have some part of the code tested before it hits production. Its ok to not have automated tests for some part of the code. Its ok to not pair program on critical code. Its ok to have 2000 lines of classes, with no tests, if it “already works”. Now I get it, right. All this does make sense, in a given context.
But, pragmatism hurts too. In this context, pragmatism means implicitly consenting to bad behavior. And again this might be ok, when you are in a bit of crunch, but when it starts becoming the norm, it begins to hurt, hurt a lot. When you see it becoming a norm, you need to start becoming a zealot for code quality. Best would be to have a good mix of zealots or for positive connotation, “craftsmen or craftswomen” on the team.
So, dont forget to promote craftsmanship just as you would promote pragmatism, especially if you are the leader of your software team.
Computellect 
Pragmatism doesn’t mean accepting bad behaviour, it means not spending additional (unnecessary) time polishing.
For example, 100% test coverage is a noble goal, but if it means that I’m testing that a getter gets and a setter sets, or that raising an exception with a particular message returns that message, then I’ve gone off the tracks.
Pragmatism means that I test things that can go wrong and typically those are things that have branches in them. 90-95% coverage might be the pragmatic goal
Not writing tests where they are necessary or not refactoring a 2000 line class that no-one understands (but “works”) is not pragmatic, it’s sloppy and unprofessional.
On many occasions, I’ve been the one to refactor the “here be dragons” class. It’s always time well spent, and as such, is beautiful and craftwork, but above all, it’s pragmatic.
Andy – I agree with you everything that you have said, except for the context in which we have heard the word “prgamatism”. What you describe is the classic definition of pragmatism as understood by a developer but not necessarily by the client (person paying for the code). For her, pragmatism might mean, not writing any tests, pushing the code to production if it “works” and getting some valuable feedback before it is deemed worthy of making any further investment like writing tests.
I am trying to argue against that view point and bring up the side effects it might have on the developer mind set, especially if continued for a long time. Rethinking, this whole thing, I should have titled my blog, Pragmatism taken too far or “Extreme Pragmatism”. 🙂
What you mention in your initial line about spending unnecessary time polishing code, I like to call that goldplating to make it obvious that it is almost unnecessary work.
Let me know what you think. I would love to hear more from you.
Some developers may inflate their estimates because the project manager holds them to their word and they may need a bit of space for unexpected problems; so too might some project owners see that the developers are spending time doing “non-productive” work like testing and think that they can cut this back and still deliver.
The definition of pragmatic that I suspect people are aiming for (but have probably never bothered to look up) is:
advocating behaviour that is dictated more by practical consequences than by theory or dogma
We need to get 100% test coverage sounds a lot like dogma. We need to write these tests to avoid the catastrophic server outage we had last week sounds like behaviour dictated by practical consequences.
When the product owner tells us to be pragmatic, we need to make them aware of the practical consequences of their decisions (and not try and win them over with theory)
Two days refactoring that 2000 line class that “just works” might not seem pragmatic, but the bug reports show that we get 30 tickets a month for it. That’s 8 developer days fixing something that “just works” instead of writing new features.
Investing 2 days now to save 8 days per month is the pragmatic thing to do
What if it is greenfield project? What if the 2000 lines hasn’t had 30 bugs against it, it just “works”. At that point the practical consequences one would like to warn about are just as good as theory.
Once you have numbers sure it is easy to tell what’s pragmatic or not. Until that point we have our own theories drawn from our experience. 🙂
If you’re really in that situation, I would put a printout of that class on the wall and put a red sticky dot on it for every time a developer has to change something in that class. (“I told you so”)
Pragmatism is never an excuse for sloppy work, and it’s very unlikely that a 2000 line class (let alone function), bug free or not, can be considered as meeting any sensible standard of quality.