Peanut butter and software planning


One of the reasons planning software projects is so much fun is that there are tons of inputs… customer requests, what the competition is doing, what the business needs to grow, supporting other groups at the company, our own personal pet peeves about the product… the list goes on and on.  Out of all of this data the thing many of us find is that our existing features just need to get incrementally better.  While there is certainly a lot of goodness is making existing features incrementally better it does come at significant opportunity cost.


Even at Microsoft we have a finite set of resources (time, talent, money), if we apply 100% of that to making the current set of features a little bit better, then we miss the opportunity to make some real breakthroughs in a very small set of areas.   For example, we chose to build the CLR rather than trying to keep making COM incrementally better.  We chose to move to the NT codebase rather than making Win9x incrementally better (albeit it took a lot longer than we expected).


 


Peanut buttering (v) – The tendency to evenly distribute resources across the full range of a product rather than focusing on a few core Value Propositions.  


 


While discussing this issue recently someone described it as “peanut buttering” the product.  By spreading out all our resources evenly across the product we lose the opportunity to focus on a few key areas where we can deliver a substantial value proposition.   Notice this does NOT mean that we forget the basics.  Of course we have to do the right thing by platform support, security, performance, reliability across the whole product.  In fact, in a bug-by-bug point of view, the product broadly has to keep getting better.  That is the price to stay in the game.  But given the amount of resources left to spend on features, we need to pick a few key areas and do an excellent job at those rather than making all features just a little bit better.


 


What do you think?  Have you been on software products that tried to make all things better?  Which would you rather have in the next version of your favorite software product a few things getting a lot better or everything getting a very little bit better?    

Comments (7)

  1. The decisions you talk about are broadly valid, but I think ignore the real benchmarks and drivers. We would all like to decide on resource allocation based on logic and the best information at hand from the development perspective. That set provides enough hard work and has logically defined limits.

    But if we produce a product, it is meant to be consumed. There is a customer who makes their decisions differently and is the ultimate arbiter of significant support and features. That is the only real driver, and the one that is least quantifiable. Especially when it comes to new key features that excite the development team.

    Maybe that’s why I like the Web application arena. It’s a lot easier to establish short delivery cycles and feedback channels! When .NET first appeared on the scene, it looked like workstation software delivery could get more like Web applications, and Microsoft would support that.

    So my meandering bottom line suggestion: keep improving the great deployment and support story for .NET workstation software! The rest will fall out from listening to the customer and acting on that in a reasonable way.

  2. BradA says:

    You are right Walter – you still have to do what customers want or more specifically what customers will value. That is fundamentally how you pick the few areas you invest in. Think of the target customer (maybe new or existing customer base) what are the few things that really get the excited? Focus just on those.

    To Val this concept of no-peanut butter is self-evident. No one that wanted to make money would peanut butter. But I have seen software projects that make lots and lots of small investments… each one doesn’t look like it takes away from the “big things”, but in sum it is a huge drain. So I am arguing for a more extreme approach… Do zero, none, zilch features outside of the target area..

    As far as their being no such thing as good and bad – well, I will not go their in this blog 😉

  3. Brad, don’t get me wrong, I sympathize your idea of "no features outside the target area" and believe that the most, especially the developers here, will like it as well.

    The truth is, my company had a number of "quality improvement" releases. The scope for those included a couple of "big fish" items, but the majority of work was devoted to exactly "face-lifting" all across the application (i.e. bunch of fixes such as changing colors, button placements, corky error messages etc). When the user experience can be improved at a relatively low cost, I kind of like that too. I don’t know if this example falls under the "peanut buttering" category however, because we were still trying to please the customer (and so, keep being customer-aware) with a reasonable amount of effort.

    I’m glad you didn’t take the "no good or bad" idea seriously – that was a tongue-in-cheek conclusion (wanted to see if somebody gets into the trap).

  4. JD says:

    I think that’s wrong, Brad.

    Peanut butter is needed, but you only put one flavor of Jelly on top of it. The jelly is your sweet new single-focus improvement, but make sure you’ve got a nice layer of peanut butter down there of solid improvements for your base.

    In 2.0 for example, wow generics are sexy. Awesome. But hell yeah I like the peanut butter of wrapping non-Exception exceptions (removing the need for catch{} mostly) and fluff like string.IsNullOrEmpty). You can try to argue that those were targetted too, but in reality there’s a grab bag of small improvements that really affect people, and they don’t add up to some grand Vision or Feature or Target. They’re just peanut butter.

    All peanut butter can be hard to swallow, and all jelly can be too much sweetness for the adults. The mix, though, is surprisingly good.

  5. 【原文地址】 Looks like I created a new word: Peanut Buttering 【原文发表日期】 03 September 08 09:28 回到早先在做VS2008计划的时候

  6. Programming says:

    Back in the early days of VS2008 planning, I captured some of our thoughts on planning and looks like