This blog has moved. Go to for the latest posts.

Monday, December 11, 2006

Quality is not just being "bug-free", it is being "valuable"

The value of a software feature/product can be divided into 4 layers. When you code a feature you probably think immediately about the "technical value", i.e. the technological improvement/innovation you are about to implement or algorithm/method.

But it does not stop there. The expert user will find in it "expert value", this is what a knowledgeable user (about the innovation/algorithm/method) can do with the feature you just implemented. This is normally seen in command line utilities like for example "grep" in Unix. A very powerful tool but very hard to use for most people.

The next layer is the "functional value", or the value a user that does not understand the technical feature can derive from the tool. As an example we can think of dificult user interfaces that allow the user to do what they want without having to type the commands (like in grep), but stil requires time to learn.

The last and most superficial layer is the "immediate value", meaning something that user can derive value from without spending any time learning the tool or reading a man page.

Many application developers do not make any distinction between these types of value for the features they implement. This led people to develop command line tools before the WYSIWYG IDEs were available, then led people to develop overcomplex graphical UIs but that's where most developers stopped! That's wrong!

Today, with the expansion of the web and pervasiveness of computers ordinary people need to use them. We, developers have an obligation to develop tools that fulfill the need to have "immediate value". Microsoft and large parts of the Open Source movement are still caught in the transition from the "functional value" to the immediate value. They have come a long way but not enough.

Users, especially avid internet/computer users, demand that the software companies don't make them lose time. I hate everytime I have to fight with Word, PowerPoint or other tools just because the developers did not make an effort to know what users really wanted to do with the software. They are taking my money from my pocket! Stop it!

If you are developing an application to be used by large numbers of users please think about what your users need (or better yet: ask them) before you code the next feature. Don't make users lose their time for you to save yours!

Many companies start understanding the importance of "immediate value" for their cusotmers. Google, Skype or Apple are good examples. Apple for example is gaining market share in the Computer and OS market not because of marketing (they were always that good), but because of a combination of price-competitiveness and excellent focus on quality products (quality is more than being bug-free).

When I see text rendered on an Mac for example I ask myself: How could we ever have used Windows for so long? (Yes, I know Vista is changing that).

Skype is another example. They came late and took a big part of the market, why? Because they did IM'ing better than any competitor. Finally someone understood the importance of voice in IM and was able to make the experience easy and appealing.

This is why I'm so shocked when I hear about certain large company CEO's saying to their people: "produce just enough quality, not more!". If you ask me they are asking for trouble!

at 21:00
RSS link

Bookmark and Share


  • Okay, I am on board with you here. It is just the notion of defect-free code that I have heard you mention that I am having trouble meshing with this. Seems like awfully long iterations would be required...

    Nice work. Thanks.


    By Anonymous Anonymous, at March 10, 2009 11:00 PM  

  • @Josh "defect-free" should be an aim. The reason for that is that it will make you fundamentally re-think how your work that will ultimately yield massive improvements in terms of quality. Never aim for less than "defect-free".

    By Blogger Unknown, at March 11, 2009 3:40 PM  

Post a Comment

<< Home

(c) All rights reserved