Brave Tech World

July 18, 2008

    One of the most interesting aspects of Agile development is to not build things that you won't use now or over-engineer a component because "we might need this in the future". That is a wonderful thing for developers and it does cut a lot of complexity and time to deliver the feature, by consequence making it less buggy.

    But what about the business/marketing sides of things?

    I've been thinking a lot in a new way of building features and I'm giving it the name "organic feature". This is not something we've been practicing at Sampa frequently, but I'm starting to think we should.

    Organic Features have two important aspects to it:

1. You write down or sketch the minimum set of functionality a feature must have to add any value.
2. You implement the minimum set before you start thinking about the additional elements.

    Organic Features have two big DONTs:

1. You don't start by thinking of all the corner cases and how you can address all of those.
2. You don't overspend time creating a UI mockup without having implemented the minimum set first

     Now, you don't ship the feature after you implemented the minimum set. That's the bar to make sure the core functionality is working, but it still doesn't mean it addresses basic scenarios of your customer. Here comes the "organic" part: You start adding to that base of features after getting the initial feedback from internal people on what they think. The goal is to add a little bit every day and at one point you have the feeling the feature is done and ready for customers.

    After you ship the feature, you'll still need a few more iterations to fix core scenarios that were missed, to fix assumptions the team made about the UX or terminology that is getting users confused, and, of course, to fix bugs.

    I'm my opinion, Organic Features are the opposite of "Spec'd Features". Spec'd features are built from the inside out, usually one or more person thinks through what it should do, what customers want, what the UI limitations are and they try to be as comprehensive as possible, since the deliverable of this work is a complete "spec".

    The core issue here is that a "spec" might write one line that converts into thousands of lines of complex code, or have a three pages to describe something that will take just a dozen or so lines of code. Using the organic feature strategy, it makes it easy for all the people involved to understand the cost/benefit of building the functionality, and as the feature gets closer to complete, more initial complex ideas may become trivial to add or integrate.

    This is just a first essay on this topic and I still have a lot to think about this, but think of Organic Feature building as a way to get rid of specs and prototyping.

Comments (2) for "Building features organically"

I spec from the "top down" and build from the "bottom up". That way, I think I have a more throught-out overall plan, and it eliminates implementing some possible dead-end features. Specs are much more maleable and have far fewer requirements from a quality point of view. So I find it worthwhile to be a bit more expansive and "future thinking" in a spec. But when it comes down to implementation, I try to do as you say - and build from the bottom up with the minimum set of functionality that can be made to work consistently. You can then decide when you've "fiddled" enough, and decide to ship the features to your customers. By Mike Koss - 7/18/2008 7:48 AM

I'm an old fart... who's was building code long before "agile" was a hot buzz word.... but as long as I've build products and code, I would always work in a manner similar to this. One simple example is that I would stive to always beable to "check in my code every night". Of course sometimes you can't do that... but if you stive to make all your code changes (even for brand new features) small enough chunks that you have something viable that "builds" and "runs" every day, then you have a huge advantage on someone who's tearing into their code for days/weeks without the hope of building an incremental deliverable. This approach doesn't just apply to UI code or websites... we stressed this same approach when building server class software at RealNetworks (back in the old days) and even the Behavioral Targeting platform at RevenueScience (which was a massively scalable system processing billions of transactions a day). I see this as less related to the spec per se, and more related to the process of building the feature. Even if the spec is some giant 300 page document... if you build your development process and plan of attack to bite off pieces, you can probably course correct the spec as you go along if you realize the small pieces are good enough and or the orginal approach was wrong and needs reworking. Anyway, good post! By Brad Hefta-Gaub - 8/2/2008 1:09 PM