I invite you to upgrade to a paid subscription. Paid subscribers have told me they have appreciated my thoughts & ideas in the past & would like to see more of them in the future. In addition, paid subscribers form their own community of folks investing in improving software design—theirs, their colleagues, & their profession. “Good, fast, cheap—your choice of two.” Yes, but… This motto reveals one truth while concealing two more. Limits of ControlThe truth revealed is that no one controls all the variables of work to be done. Anyone dictating all three dimensions at once is either:
An intervention is to offer to fix any two dimensions & deliver the bad news about the third. IME this intervention is not appreciated, but I, in my geeky way, feel compelled to offer it. Not Necessarily A TradeoffThe first truth concealed is that the relationship between the variables is neither simple nor linear. In particular, improving quality often results in lower cost & shorter timeframes. Only up to a point, it’s true. You can have too much quality for your purposes & end up late & expensive. But if the time & money answers aren’t acceptable, think about what you can do to improve quality to reduce waste, rework, or variable delays. Only For Fixed WorkThe second truth concealed is that the motto “good/fast/cheap, pick 2” only holds for fixed quantities of work. If I want 100 posters printed, then absolutely I can have them Friday for $100 with one color of ink. If I want 4 colors, I’ll have to wait until next week or pay $200. Software ain’t like that. We do the work to discover what work needs doing. I always objected to the word “requirement”. I noticed that if the software shipped with the right half of the “requirements”, the customer would be delighted. Especially if most of the features were discovered during development. So that original list weren’t “requirements”, because they weren’t required. (Hence “stories”.) To maximize the value of software, the most important dimension to control is scope—what features we include & which we leave out for now. SkillsThe whole reason I reiterate the above is because I realized in conversation with Jessica Kerr that the scope-first model assumes 2 skills which may or may not have been acquired by the team:
Both skill sets are social first, tools & techniques second. Practice. Experiment. Squeeze the inevitable lemons. ConclusionAnd that’s why in XP we talk about scope management as the primary control variable. Quality we fix at “damn near the best we can do” (as long as lives aren’t at stake, in which case it’s “better than the best we can do”). Then we negotiate scope continuously & let time & money take care of themselves. That’s the theory anyway. In practice folks on the upside of power differentials often pretend to fix all 4 dimensions & you know how that story goes. But we really can offer transparency & control, up to a point, by managing scope. You’re currently a free subscriber to Software Design: Tidy First?. Buying me more time to think & write means more thoughts & ideas for you. |