On Hating Your Tools
I recently read Why software developers (quite honestly) hate Agile, which argues that the Problem With Agile is that everybody's going it wrong, that the original pure idea was "hijacked by an army of certified Scrum masters". If we go back to the Real Agile we'd like it again. This got me thinking about one of my major outside view problems with Agile, which is the fact they don't really follow "hate your tools".
My first blog post on my site was "Hate Your Tools". I want to write a followup that captures my ideas better, but I can never quite get down how we need to hate our tools. The original formula was "one bad thing you take on, one good thing you give up", but that no longer feels like it captures what I'm going for.
I don't think it's possible to be a master in something without being absolutely aware of its shortcomings. Every tool, process, anything has its flaws, something that makes it unsuitable for certain purposes. And not in a fixable way, like "oh it kinda sucks for this but we can make it work with a little practice." I'm talking an existential unsuitability, the kind that cannot be fixed without fundamentally changing what you're doing.
Take randomized/generative/property-based testing (PBT). Incredibly effective for finding bugs. But you give up on having easy oracles- tests where you know what the expected output should be exactly. In many cases, an oracle is what you want, as it best captures your internal mental thought process on what you're trying to do. You can sometimes get oracles in randomized testing, but it's a skilal that works on a case-by-case basis. It's not as general or as automatically obvious as it is in manual example testing.
Is that a reason to give up on PBT? Absolutely not! PBT is a fantastic technique and I wholly recommend it. But it means we need to be aware of the weaknesses of PBT, and when we should use it versus manual testing. That's what it means to "hate your tools". To know the existential limits and tradeoffs in a way outsiders do not.
That's what bothers me about so much agile advocacy. There doesn't seem to be a sense of the cases where Agile practices get in the way, or where managers need more power, or anything. Sometimes you hear "safety-critical systems", but that's dodging the question: it's not asking what fundamentally are the limitations of Agile, it's just picking a domain that's obviously pathological to everything and going "well if you're DOING THAT..." Praising with faint damnation.
I'd trust Agile evangelists more if they had a clear sense of what the drawbacks were. I don't know what they are, because I'm not an Agile expert, but they must exist, right? I went to an Agile talk where I asked "when does this break down", and the presenter responded with "what, like people are having too much fun?" That's an immediate red flag to me.
Anyway, couple housekeeping notes:
- I need a name for this newsletter. If you have any ideas, let me know.
- I want these emails to be more of a dialogue than a monologue. Obvs I can't respond to most people, since there's over a hundred of you great folk, but feel free to share your thoughts on this stuff.
Thanks again for subscribing!
If you're reading this on the web, you can subscribe here. Updates are once a week. My main website is here.
My new book, Logic for Programmers, is now in early access! Get it here.