I hate the notion that we're doing the least we can to get by. And it's popping up everywhere:
- In Software by Numbers, we see the notion of "Minimum Marketable Features" - the smallest chunk of work that a customer or potential customer would find viable.
- Extreme Programming espouses the notion of Doing the Simplest Thing That Could Possibly Work. When you solve a problem, solve it in the simplest way possible; that is, make the smallest change possible to get the desired functionality.
- Many SCRUM practitioners require that stories be small - anywhere from "fits in an iteration" to "no more than X days" (where X is smaller than a breadbox!). Yet you still have to have a shippable product at the end of each iteration. And if it's a shippable product, then you've met customer expectations - with little changes only.
I can understand the desire behind these concepts. Overbuilding something, or spending a long time building a "framework" or a "platform" can take you away from what your customers really want. When you're overplanning or overbuilding you can work for a long time on something only to find that the market has moved on you, or your customers don't like it, or whatever.
I really think the notion that we're all going to do as little as we can get away with does a disservice to the customer. Plus, that's not what really good development teams are doing. Good development teams are distilling ideas to customer desires - expressed and unexpressed - and building only that.
I don't think the problem is in what we're doing; I think the problem is in what we're calling it.
So down with minimums. Let's give it a better name. We're not doing "minimum features", we're not doing "small changes". We're not doing "simple things" or "easy things".
We're doing focused development*.
I think that sounds a lot more like what we really do.
* I'm open to better names... ideas?