magpiebrain

After hearing the “good news(ongoing – Sunny Boy)”:http://www.tbray.org/ongoing/When/200x/2004/03/15/SunnyBoy that Tim Bray has joined Sun, I spent a little time reading over some of his old posts and came across a small piece on the “80/20 point(ongoinig TPSM-12:80/20 Point)”:http://www.tbray.org/ongoing/When/200x/2004/01/14/TPSM-8020. Briefly put, the 80/20 rule defines a point in a soft are development where you’ve achieved 80% of your requirements with 20% of the effort. Tim then looked at certain pieces of software which seem to solve most of what needs to be solved without going overboard (who have reached this 80/20 point and stopped) and compared it to software who went for every last piece of functionality. Here, the argument is that those pieces of software that solve most problems as simply as possible work, whilst those that attempt to be all things to all people invariably fail.

You may quibble over the exact percentages, or some of the comparisons made by Tim, but any of you that have developed sizable applications will of seen this yourself. Now I could proceed to rant about how TDD (actually any development process with short iterations) can help you quickly identify this point and make a judgement call as to whether or not to continue, but I won’t (apart from this sentence or course). I can however draw a simple analogy between software and books. Short books are by their definition shorter than long books (I get the feeling I may be dumbing down here, but anyhoo). They have less time to get you interested and get their point across before they finish. By the same token, software which has decided against this other 20% effort will have less to explain – it is quicker to learn because there is less of it to learn. You also don;t have to worry about the fact that it has to cater for the extra 20%. Likewise you don;t have to turn as many pages in a short book as in a long book. I kind of loose my point right around here, but I’m sure I had lots more to say when I was thinking about this during my sushi. A simile too far perhaps…

The issue of course is whether or not this extra 20% functionality results in a more complex piece of software for the other 80% of the functionality. If the answer is yes, you could make a strong argument in favour of not doing it, or even look at refactoring the application. You can, I think, always argue in favour of sushi.