The 80/20 Rule of Software Development

The IT version of Pareto's 80/20 rule says that 80% of users only use 20% of the features of most software, especially of big applications like Word.

This has led to complaints about bloatware - software that keeps expanding in size to ridiculous extents (Adobe software immediately leaps to mind.). Bloatware can be attributed to a few main causes:

• the never-ending addition of extra functions, bells and whistles and eye-candy (to justify yet another upgrade for customers to pay for);
• sloppy coding that is not optimised for size or speed.
• attempts to make it compatible with other software or standards (e.g. adding support for Microsoft networks' Open Directory will require a fair bit of extra coding)
• trying to radically new basic architecture while remaining backwardly compatible with old versions (e.g. Windows Vista still supports DOS commands, and can run programs from Windows 3.1)

This leads many software developers to develop "liteware" applications that supposedly include only the 20% of functions that the 80% of users actually use. Their big benefit, they say, is "only pay for the features you need."

Most of this software fails miserably. Why?

Because each user tends to use a different 20% of features of the software! While (for example) pivot tables in Excel would be useless space-wasting for some users, it is a vital tool for others. Similarly, word count in Word is never used by some people, but others (e.g. students) use it all the time.

Solutions?

1. Develop different releases of the same package (much like MS does with Vista). A basic cheaper package has the basic functions. The more esoteric or specialised functions appear in a different, more expensive version of the package.

2. Create the software in a modular fashion so extra functionality can be added after purchase. Many top software packages owe their popularity to this ability to "grow" new powers over time - such as Photoshop's filters, Firefox's "add ons" and Dreamweaver's or Filemaker Pro's extensions.

3. Survey your users (or potential users) and find out what features they actually want. Develop your feature list in this way:

• Essential features
• Desirable features
• Luxury features

Code them in that order! There's not much use in a text editor being able to colour-code Delphi code but not be able to search and replace properly!

4. Optimise your code.

• Remove invariant calculations from loops (calculations that are repeated many times but the answer never changes during the lifetime of the loop. Such calculations should be done before the loop begins)
• Use more efficient algorithms for things like sorting. The study of sorting algorithms is somewhat of an art form.
• Remove unused variables and orphaned code.
• Use the right variable type for the job. E.g. if a number will never exceed 255, use byte type rather than integer. Use Boolean type for flags and on/off options. Avoid variant type in VB.
• Build in data validation to reject invalid data so later on you need less code to catch and respond to the errors caused by the dodgy data.
• Learn, and fully exploit the available functions of the programming language. A built-in function will work a lot faster than one you create yourself in a custom subprogram or function. e.g. did you know there is a reverse INSTR function in VB that can find a substring starting the search at the end of the larger string?