
Software Design is Human Relationships: Waiters, Changers, and Sufficiency - KentBeck
https://medium.com/@kentbeck_7670/software-design-is-human-relationships-part-2-of-3-waiters-changers-and-sufficiency-4c0bb9a08d23
======
JamesBarney
Strange naming.

> 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).

Is this a roundabout way of describing stakeholders and developers?

Structure changes vs behavior changes also seems like a circuitous way of
describing refactoring versus feature work.

I don't think I got the essay. Would someone who liked it mind sharing what
insights you got out of it?

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".

~~~
cs02rm0
> Is this a roundabout way of describing stakeholders and developers?

Maybe, but not the way I skim read it.

The chord it strikes for me is nearer Agile vs Waterfall, between those who
would rather quickly get a thin slice put together and those who (at the
extreme opposite) would endlessly design, document and polish before producing
it.

On a current project I'm the developer who wants to build the features out
quickly and the stakeholder is a government client who wants to go very slowly
with all the design and documentation upfront.

