A 2012 tweet said, “for each desired change, make the change easy (warning: this may be hard), then make the easy change” and clarifies in a comment “Glad you found it helpful. Sometimes when the work is hard it signals that we're doing it wrong. Sometimes it's just hard.” [1]
A 2020 tweet claims to have an older form of this insight c. 2000 which would be written in DOT as
So the claim is that new feature development per se should always be “easy” (in the Rich Hickey sense, "adjacent" or "in nearby reach"), but that there should exist potentially a lot of hidden work which is not feature development.
For example, you build a log ingester which runs super fast, it buffers the logs and batch inserts them into a NoSQL store, gets very nice throughput... But then you want to add a feature for which your NoSQL storage just doesn't index right or so. The advice here is to abstract the problem first, figure out where it creates friction. Are these for example ad hoc user searches? Or do we know them ahead of time? Those create new structural constraints, for some work that is not directly tracked... Perhaps just adding some appropriate index, computing periodic summary rows, streaming the recorded logs into a MapReduce type cluster, switching to a relational database that better matches your domain, or whatever.
None of this work directly yields value to your customer, indeed you are attempting to do a pure refactor with no observable changes to the clients. But, because you abstracted the problem you now have the ability to easily solve a bunch of nearby problems at once, and you use this to solve that target problem.
Why would Kent Beck want this? Because he is talking about extreme programming and agility and changing the software in response to user feedback and all that. He needs that freedom to solve nearby problems easily, because the core tenet of Agile is that you ship ≈crappy software and let your customers tell you what's crap about it, rather than pretending to know yourself. “Hey the colors are awful but here's a first pass.” “I don't care about the colors, I care that you think every purchase tracked by the system belongs to a contract.” “Uh. What. I thought you said contracts had the purchases underneath them? We had a long conversation about this!” “Yeah but just use your head! Sure we usually purchase things for contracts. But we also purchase things for bids, or for demo products, or to upgrade our tools...”—that is the Agility problem in a nutshell, I want to find this out before the codebase is 30,000 LOC+ and fixing the broken data model requires three months’ rework!
So Kent Beck needs to be able to offer a client a “change/feature” with the understanding that they might say “What. On. Earth. No. Just, no. What?” and say “oh ok my mistake I can tweak this to do what you want, give me a day or two.”
My own version of this is the aphorism, “Magic is just cleverly concealed patience.” What I mean is that if you dive into what magicians do, you will often discover that it just required a lot of prep work: and the reason that you assume magic is you can't imagine someone spending that much time on that stupid of a thing. “Who would buy 52 decks of cards just to assemble one that is ENTIRELY made up of the Jack of Spades?” Well, a professional magician would. Some sleight of hand, they fan put a normal deck, swap the decks so that you shuffle the Jack of Spades deck and pick any Jack of Spades you’d like, how about that. Same happens with professional kitchens prepping everything before service. If you cleverly conceal the patience, you get a reputation for working magic at your job.
I feel like this is one of those things that seems obvious but is a bit more deep than that.