Software is subject to “size creep.” Operating systems and application software packages become larger and more complex with each release, yet most people use only a fraction of the functionality.
During a visit to Toronto last fall, Bill Gates said, “Simplicity has become the top priority in everything at Microsoft.” Announcements about Internet Explorer 5.0 indicate that this priority is being realized. Responding to feedback about the increasing complexity of Internet browsers, Microsoft is making its browser simpler to use.
It is good that Microsoft and other vendors are simplifying applications that are used by millions of people. But, even when building applications for delivery to a small user community, we should follow this philosophy. By challenging our teams to design and build simple solutions, we can: deliver software faster; produce quality software at lower cost; ensure the software is easier to maintain; and make it easier for users to learn and apply applications.
We must avoid design decisions that increase the size and complexity of software, such as:
Multiple formats. It is easy to specify a report for every occasion. If the development of a report costs around $20,000 (for specification, coding and testing) we need to determine the real value of providing alternate formats. The provision of a report writer, like Crystal Reports, and access to simple, well-defined data structures may give more value than numerous report variants. We should also support only one or two export/import formats that can be used with multiple applications. A comma-delimited or fixed-field file can be imported into Word or Excel. The cost to build application-specific, automated export capability is often greater than the long-term benefit.
Support for novice users. Advanced and novice users often require different support. Rather than developing two sets of commands or functions, it is less expensive to add wizards to guide users through advanced functionality. Also, the use of intuitive interfaces that follow Windows standards will make the provision of novice features less necessary.
Automated decision making. It is tempting to automate every aspect of a process, including areas that are performed better by humans. To embed complex rules in software (for example, filtering content in a Web search) often makes them difficult to maintain. Unless you are using a rule-based inference engine, automate only the highly repetitive steps.
Automated conversion. Conversion utilities can be expensive to write but are used only a few times. Since much data cleanup requires human intervention, it may be cheaper to apply temporary human resources to many parts of a conversion effort. Where appropriate, consider the use of inexpensive offshore resources.
Run everywhere. The desire to make software run on many different platforms is theoretically commendable and is fueled by the promises of the Java environment. In practice it will cost more than it is worth. Most organizations need to support only a single platform and don’t have to worry about Sun or Oracle dethroning Microsoft from the desktop.
Questions to ask of your development teams and users are:
– Do we really need this function or feature?
– Are we using proven technology or the latest toy?
– Can we buy functionality (packages or custom controls) rather than building it?
– How often will it be necessary to use the software?
– Are there alternate ways of achieving the same goals (even if they are manual)?
– Can we change business processes instead?
– Is the cost justified?
– Can we build only the 20 per cent of the software that performs 80 per cent of the work?
Keep it simple to be successful.
Hughes is a vice-president of software development for SHL Systemhouse in Toronto and was responsible for the development of SHL Transform, a knowledge-driven process management tool. He can be reached at jhughes@shl.com.