3 ms·
TL;DR: the key is to realise that you wouldn't be denying them a revenue stream. You would help them improve it. Look at it from a broader perspective. If you
by kqr 4y ago
TL;DR: the key is to realise that you wouldn't be denying them a revenue stream. You would help them improve it. Look at it from a broader perspective.
If you say "You've projected so-and-so much revenue from this feature. Our projection is that it's implementation will cost this, future maintenance that, and it will introduce bugs which will lose you this much revenue and cost this much to fix. We propose you change the spec this and that way, and you will get out of most of the drawbacks while still retaining most of the benefit"
any sane business would not go "shut up and go home" but rather engage "okay, but what about sub-requirement xyz -- did you consider that in detail?" and from there on you can create something amazeballs together.
- h0l0cube 4y agoEither way you’re still fulfilling business requirements. If there’s a more efficient way to serve the same goal, you’re talking optimisation, and that absolutely aligns with a smaller code base (again the actual point of the article), but not ‘less features’
- kqr 4y agoWell, sometimes it's better for the business with a feature present, sometimes with the feature absent, sometimes with the feature exchanged for another that's even better. It all depends on the feature in question and the business context.
- h0l0cube 4y agoAnd to my original point: that a business requirement adds more potential bugs is not sufficient to obviate implementing it. The only sufficient argument is that it doesn’t provide the product owner as much value as it costs to implement and maintain, but rarely is the developer in a position to judge that - they just provide the cost estimates and the PO can decide if they want to wear it or not.