Hillel Wayne - Computer Things: 2019-2020

Originally published on 2019-10-04. Available online here.

I recently read Why software developers (quite honestly) hate Agile, which argues that the Problem With Agile is that everybodys 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 wed like it again. This got me thinking about one of my major outside view problems with Agile, which is the fact they dont 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 Im going for.

I dont think its 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. Im talking an existential unsuitability, the kind that cannot be fixed without fundamentally changing what youre 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 youre trying to do. You can sometimes get oracles in randomized testing, but its a skilal that works on a case-by-case basis. Its 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. Thats what it means to hate your tools. To know the existential limits and tradeoffs in a way outsiders do not.

Thats what bothers me about so much agile advocacy. There doesnt 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 thats dodging the question: its not asking what fundamentally are the limitations of Agile, its just picking a domain thats obviously pathological to everything and going well if youre DOING THAT Praising with faint damnation.

Id trust Agile evangelists more if they had a clear sense of what the drawbacks were. I dont know what they are, because Im 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? Thats 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 cant respond to most people, since theres over a hundred of you great folk, but feel free to share your thoughts on this stuff.