7 ms·
I see more gray in my beard every morning. And the thing about "...to 80% completion" is that the first 80% of value is captured in the first 80% of effort, and
by throwanem 7y ago
I see more gray in my beard every morning. And the thing about "...to 80% completion" is that the first 80% of value is captured in the first 80% of effort, and the last 20% of value in the other 80% of effort. It's important to know when to follow that ROI graph past the knee, for sure. But it's just as important to know when not to.
(I mind me of a time a few years back when I was surprised to learn that the right method of exception handling, for a specific case in some work I was doing on a distributed system, was none - just letting it crash and try again when the orchestrator stood up a fresh container. It felt wrong at first; ever before I'd have instead gone to a lot of painstaking effort to reset the relevant state by hand, and my first instinct was to do the same here. But crashing turned out to be the right thing to do, because it worked just as well and took no time at all to implement.)
- specialist 7y agoYa. Sorry, I'm still struggling on how to phrase this. I'm totally on board with 80% feature complete, MVP, biz case, etc. What I'm trying to articulate, here and elsewhere: implementations that apparently work, but not really coders who don't check their own work doing the bare minimum to get awarded the agile velocity victory points futility of arguing definitions of "done" lack of feedback loops that cliche about managing to metrics leads to undesired outcomes the personal cost, burden of craftsmanship in a "break things and move fast" world