Brave Tech World

July 18, 2008

FRI 18 JUL

Building features organically By Marcelo Calbucci

 

    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.