Monday, February 11, 2008

Skating By

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.

But...

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?


2 comments:

  1. Interesting point. I agree that the choice of words will frequently color how a concept is received.

    For the XP concept, "Simple Design" is perhaps really "Design for Today". The point is never to skimp and avoid work (always refactor!),but rather to avoid building things that will never be used. Don't define a function that takes a boolean flag that is always true, because you might want to have false do something different later. If you haven't heard them already, Client has some great horror stories from our pre-XP past...

    ReplyDelete
  2. We are not doing the least to get by, we are leaving behind the least complexity and confusion. This requires not the least of us, but often (for me) the most -- the most discipline, knowledge, refactoring, exploratory testing, whatever.

    The distinction, for me, is between simple and easy. Blaise Pascal once closed a letter with "I have made this letter longer than usual because I lack the time to make it shorter."

    Simple Design in my code (requisite object model, no duplication, clarity, brevity, low cyclomatic complexity) is hard to do.

    Proper unit test code coverage is hard to accomplish.

    Robust unit test suites (that don't break all the time, and can be repaired straightforwardly) are hard to create and manage.

    Short unit tests are hard to write.

    Small user stories are hard to boil down to.

    All these "simple" ends require "harder" means.

    But what they appear to win for me is higher ROI, and lower TCO code and tests.

    For me, simple ends are worth the complex means. Simplicity is worth it!

    Simplicity is hard. Viva simplicity!

    ReplyDelete