https://yosefk.com/blog/engineers-vs-managers-economics-vs-b...> ...It's a common story and an interesting angle, but the "best vs good enough" formulation misses something. It sounds as if there's a road towards "the best" – towards the 100%. Engineers want to keep going until they actually reach 100%. And managers force them to quit at 70%:
> > There comes a time in the life of every project where the right thing to do is shoot the engineers and ship the fucker.
> However, frequently the road towards "the best" looks completely different from the road to "the good enough" from the very beginning. The different goals of engineers and managers make their thinking work in different directions. A simple example will illustrate this difference.
> Suppose there's a bunch of computers where people can run stuff. Some system is needed to decide who runs what, when and where. What to do?
> * An engineer will want to keep as many computers occupied at every moment as possible – otherwise they're wasted.
> * A manager will want to give each team as few computers as absolutely necessary – otherwise they're wasted.
> These directions aren't just opposite – "as many as possible" vs "as few as necessary". They focus on different things. The engineer imagines idle machines longing for work, and he wants to feed them with tasks. The manager thinks of irate users longing for machines, and he wants to feed them with enough machines to be quiet. Their definitions of "success" are barely related, as are their definitions of "waste".
> The "good enough" is not 70% of "the best" – it's not even in the same direction. In fact, it's more like -20%: once the "good enough" solution is deployed, the road towards "the best" gets harder. You restrict access to machines, and you get people used to the ssh session interface, which "the best" solution will not provide.