Subscribe to our mailing list

* indicates required

Friday, April 10, 2009

Most time spent in development is wasted

Yesterday, I was thinking about complexity in software systems and I had a kind of "Aha!" moment. It occurred to me that most of the programmer-hours time spent in product development are wasted.

We know that something like 30% to 40% (some experts say 45%) of the features in a software system are typically never used, while another 20% are rarely used. That means over half the code written for a product seldom, if ever, actually executes.

The irony here, if you think about it, is mindblowing. Software companies that are asking employees to turn their PCs off at night to save a few dollars on electricity are wasting huge dumpster-loads of cash every day to create code that'll never execute.

Is it worth creating the excess code? One could argue that it is, because there's always the chance someone will need to execute the unused bits, at some point in time. In fact, if you think about it, there are many things in this life that follow the pattern of "you seldom, if ever, need it, but when you need it, you really need it." Insurance, for example. Should we go through life uninsured just because we think we'll never experience disaster?

Unused software features are not like health insurance, though. They're more like teacup and soda straw insurance. Insurance at the granularity level of teacups is ridiculous (and in the aggregate could get quite expensive). But that's kind of the situation we're in with a lot of large, expensive software systems -- and a fair number of popular desktop programs, too (Photoshop, Acrobat Professional, OpenOffice being just three). You pay for a huge excess of features you'll never use.

There's no magic answer to the problem of "How do you know which features not to write?", obviously. It's a judgment call. But I think it's critical (for vendors, who need to cut costs, and customers, who are looking for less-expensive solutions to problems) to try to address the problem in a meaningful fashion.

What can be done? At least two things.

We know that formal requirements tend (pretty much universally) to err on the side of feature-richness, rather than leanness. It's important to address the problem early in the chain. Don't overspecify requirements. In software companies, product managers and others who drive requirements need to learn to think in terms of core use cases, and stop catering to every customer request for a specialized feature. There's a cost associated with implementing even the smallest new feature. Strive to hit the 80% use-case. Those are the scenarios (and customer needs) you can't afford to ignore.

If you're a software buyer, stop writing gargantuan RFPs. Again, figure out what your core use-cases are. You won't know what your real-world needs are until you've been in production a year. Don't try to anticipate every possible need in advance or insist on full generality. Stick with hard-core business requirements, because your odds of getting that right are small enough as it is.

Another approach to take is to insist on modular design. Factor out minority functionalities in such a way that they can easily be "added back in" later through snap-ins or extra modules. Create a framework. Create services. Then compose an application.

Product managers: Quit listening to every ridiculous feature request from the field. Don't drive needless features into a product because one customer asked for this or that edge-case to be supported. Make it easy for customers and SEs to build (and share) their own add-ons instead.

Infrequently executed "baggage code" is costly -- for everyone. Let's stop demanding it.


  1. Amen to "stop writing gargantuan RFPs". It is a waste of time to the company and to the vendor trying to fulfill it when only a fraction of it will do just fine. I have found that most RFPs contain a wish list from every department, every manager that could ever touch the software as well as every buzzword of the day. Companies would fair much better to quickly get the best core functions delivered.

  2. Great post. I also agree that the core use cases are the most important. I also think it's interesting that *developers* (I used to be one) add unnecessary code/features so it's not just the product managers (I've seen lots of this). So the product manager's role is certainly key, and it's not about *gathering* requirements but in developing requirements based on all the inputs the product manager gets (rejecting some, finding similarities in others, adding ones that might solve many issues at once, etc). These core use cases can't shy away from the essential issues though, even though that does mean getting into the details. Determining what's important and specifying to the right level of detail to achieve that is the key.

  3. Anonymous9:49 AM

    I think it depends on the kind of software you write, but if you are writing for a big audience, chances are that 100% of the features you write will be used, just not by the same people.

    There are millions of people using photoshop in the world, and every feature *you* don't need, someone else can't live without it. A guy making a movie is going to use very different photoshop features that a guy making a print ad, or a web banner.

    So, how you decide what are the needed features in say OpenOffice? Everything I need? But that will surely not include some features you want. So we can set for everything you and I need. But what about John? He uses pivot tables, even when you and me don't need them. So let's add pivot tables too. And when you end up including everyone's needs, you end up where we started.

    Actually when you buy acrobat, you are not "paying for a huge excess of features you'll never use", but more like "paying very little to buy a complex program that does what you need, thanks to economy of scale, and getting extra features that you won't use for free."

    If you hired a team of developers to develop your own acrobat with just the features you need, it wouldn't be cheaper, it would be much more expensive. The reason you cam buy acrobat so cheap is because it is targeted to millions of people, not custom targeted to you. And Adobe needs to please all of its customers.

    Here is an interesting reading on this subject:

  4. Hey Kas. All very true! (Except maybe you need to substitute MS Office instead of OpenOffice for a much more relevant example!)

    Your discussion here is focused on the "traditional waterfall" development life-cycle. However, what's über-interesting to me is the "continual beta" approach taken by Google:

    1. Start small (in terms of features, not users)
    2. Let your customers tell you what's missing
    3. More importantly, watch what your customers do
    4. Incrementally add features that have the most value

    We can see this in the extreme with Twitter. Instead of just employing the continual beta approach, Twitter has instead opened their system and allowed third parties to provide the missing functionality. Twitter can now cherry-pick those features (or buy/invest in the companies that provide them, e.g.

    Were we daft all those decades for not seeing how powerful and efficient this is??????!?!? :-)

  5. @Anonymous: the answer is to allow third-parties to provide the missing pieces. Joel got it all wrong in that post because we couldn't yet see the answer back in 2001.

    Here's another success story for the third-party strategy: Firefox.

  6. Anonymous11:13 AM

    @unscriptable: And you are saying firefox is not bloated?
    I use it myself (because I don't have problems with bloated software), but firefox and ie are normally *the* example used for bloated browsers. (normally compared against webkit that is slimmer)
    But then, the world is using firefox and ie, not webkit. I would score a point for joel there.

    (And btw, webkit is on a race to add features, lots of css3, offline storage, gradients, shadows, web fonts, etc... just visit their blog). So they are not trying too hard to avoid bloat.

    I probably don't use more than 30% of the features a bare bone installation of firefox has, so yes, I could use a much lighter version of firefox.

    About plugins, actually both ms office and adobe allow you to write extensions, and in fact, if you are a professional, you are probably going to spend more money in photoshop filters than in in photoshop itself. Which kind of defeats the point of the article that a slimmer product would be cheaper.
    And third party solutions are not the holy grail either, while they solve this perceived problem of bloat, they introduce a lot of dependencies, many security holes, and a much difficult to customize app. Now instead of just installing one application, you need to install 50, and you need to figure out which ones you need, and which ones you trust.

    About the "continual beta" & "waterfall" models, I don't think a single company out there adds features out of the blue, because some manager thinks they are useful. I say this as a developer myself of a product with some thousands of registered customers. The stream of requests for new features I get is enough to keep me busy for the rest of my life. I just can't imagine the amount of feature requests Microsoft gets, and you would be naive to think they don't use that data, and they don't watch which features are more requested, and implement that.

  7. Just because the feature isn't used does *NOT* mean it didn't add value.

    Those "wasted" features can also be used as selling points. A helluva lot of customers ask for features they don't need or really want and a large feature list (even if it's filler) can close a sale.

    We have a few of those in the product I work on.

  8. Isn't this a reason to look for a more careful analysis phase? where does the code/the features, which are not used come from? Who asked for it in the first place?

    I know, just questions, but answering these questions will help to reduce the problem.

  9. This is an argument for the Ancient Wisdom of UNIX, isn't it? Build a lot of small, reliable utilities that do one thing optimally well, but which offer plenty of options about how you do it through a scripty API, so you can build clever things out of them. (Python tries to be like that too.)

  10. I second "Anonymous"'s comment above -- things are not really so simple most times. Also you have to add in the fact that software needs to evolve and add new features with new releases to keep up the perception that what the customer gets is the absolute greatest/best/on par or better than what the competition has. So features need to keep getting added.

  11. Hi Kas,
    I'll quote your blog when discussing the feature list and making an estimate for a current software project. You're right on the spot with suggesting a modular design and allowing for the last 80% (percentiles 80 to 160) to be added later on top of robust services and modules with few pre- and postconditions.

  12. I second anonymous. This thing is not so simple. You need to figure out what marketing/sales should do, given the lean features. Like anything else, you need to pitch for your niche.

    Modular design is nice, great in fact. But you need to take on the fact that extra modules to install are considered extra complexities. Anything with unnecessary extra complexity can hurt the number of your user base, thus sales. Of course, that may not hold water for certain specialized application (Photoshop and yes, Firefox as well). And you need to count on your support cost too.

    Of course, sometimes, some of the plugins may not play well with other plugins, and yes, you have to consider that too.

    Most of the time, by keeping a feature as core instead of plugin, you are likely to make it more lean instead of core + the plugin.

    As with anything else, there are many ways to slice the cake. Pick your user base, know your limit (cash, resources) and choose your approach. If there is just one way to develop things, grandmas will be using Linux on their PCs right now.

  13. Hendry Betts10:30 AM

    I've got to say-- frameworks as a development paradigm should be the standard. Core functionality that can then be added into using the framework is far more valuable than a huge codebase to start.

    However, there are ways to make frameworks and there are ways to make frameworks. If you want to see a COMPLEX and almost INCOMPREHENSIBLE framework look at Confluence (the enterprise wiki). It's got so many levels and layers that one would have to devote many hours just to understand them before you could make use of them and even then the "usefulness" of the work would be in doubt.

    Just MHO

  14. Hi Friend,
    Congratulations for this nice looking blog. In this post everything about Web Development. I am also interested in latest news, sometimes i posted on Customized application development

  15. Nice post to read as an app developer. I have developed a number of apps with the help of various cross platform mobile app development tools described above.


Add a comment. Registration required because trolls.