Strange naming.<p>> Even though both groups’ incentives are ultimately the same, the short-term incentives they face diverge. Waiters stereotypically want more behavior changes faster, focused on either latency or throughput. Changers stereotypically want the structure clean and tidy (not all changers are the same — part 3 addresses the changer-changer relationship).<p>Is this a roundabout way of describing stakeholders and developers?<p>Structure changes vs behavior changes also seems like a circuitous way of describing refactoring versus feature work.<p>I don't think I got the essay. Would someone who liked it mind sharing what insights you got out of it?<p>My summary would basically be "Make sure features are added to keep stakeholders happy. But also try to interweave some refactoring to keep yourself happy".