Modest Software Tools¹

by
Robert Fabian


Too many of our software tools are immodest. They attempt too much. They are unnecessarily complex. They are too difficult to learn and to understand. With the help of such tools, our performance is less than what it can be, and less than what it should be.

There are many examples of immodest commercial applications. The first part of this article describes what is happening with commercial packages. But immodesty is not confined to commercial applications, many internally developed applications are also immodest. The second part of the article describes how internal applications become immodest and what should be done about it.

Commercial Applications

The trade press has begun to talk about commercial "bloatware" - software packages that have too many (unnecessary) features and take up too much space. One recent straw-poll (on the PC Week Web site) had three out of four users voting that Microsoft should pull back from its "bloated" Office 97 product family. Users are reluctant to fill their hard drives with these "new", "improved", and "extended" applications. Office 97 is only the most prominent example; there are other examples from all major desktop software vendors.

There had been a nearly universal market-driven push to add ever more features to software packages. The logic appeared to be inescapable. Users would select based on the feature list for competing products. The product with the most features would win the most market-share. Software companies felt they had no option but to add feature upon feature. But user resistance to this inescapable logic has begun to emerge. It often surfaces as a reluctance to "waste" so much disk space on "bloated" applications.

In theory, a reluctance to fill up disks with bloated applications should be easy to overcome. The cost of disks is dropping so rapidly that the new applications cost less to store, today, than did the old versions they are to replace, when those were new. In a very short time, the cost of the required extra disk space will be low enough to be insignificant. This article takes the position, however, that user resistance has a sounder footing than just the cost of storing the new bloated applications.

To use any tool effectively, and efficiently, you need some level of understanding for how the tool works. This is true for simple physical tools like hammers and saws. It is true for more complex tools like the automobile. The user needs to understand that using the tool in this fashion will produce that result. With an automobile, accelerating out of a curve will yield a superior result to accelerating into a curve. The same kind of understanding is required for software tools.

There is an additional element of complexity with software tools. The context for use of a physical tool is a given. The automobile designer develops vehicles that will work on existing roads. The hammer designer develops a tool that will work with existing nails. With software tools, that context can be completely open. The user of a software tool needs to understand context as well as causality. An example from the early days of word processing nicely illustrates the importance of context.

Ten years ago there were two different contextual models for word processing. One model was based on the idea of pages. Every document was divided into pages, and all editing took place on a single page. Repagination was required after every major change. The alternative model viewed a document as a long stream of characters, sentences, and paragraphs. The document would be "chopped" into pages at the time of printing, and not before. DisplayWrite was an example of a package that used the first model. WordStar was an example of the use of the second model.

The great appeal of DisplayWrite was that people came with a built-in understood the context. It took the "natural" view of a document as nothing more than an ordered series of pages. But repagination really was a pain. As people gained familiarity with word processing and the potential of electronic documents, the WordStar model came to be generally accepted. Understanding the context is important to understanding how and why a software tool works as it does. Both of these early models were "simple". The current word processing packages take an incredibly rich view of "document".

The user must develop a reasonable level of understanding for this rich document context in order to master any of the popular word processing packages. Gaining that understanding is no longer simple, nor is it immediate. The argument has been advanced that the user, concerned about a limited context, does not need to understand the entire package in order to use it effectively in that limited context. That is only be partially true. The other, irrelevant, features intrude, at least to the extent of confronting the user with choices they do not necessarily understand. Text Processing illustrates the point.

The market will correct the problem of bloatware, or immodest commercial applications. Many users are increasingly reluctant to upgrade to the next, great release of popular commercial packages. There has been well founded speculation in the trade press that the new versions of the office suites that are due in 1997 will be the last to add features upon features. What comes next will be far more modular, giving users the ability to select only the features that are important to them. Indeed, this modular approach seems central to how Corel and Lotus expect to compete with Microsoft in the office suite market.

Internal Applications

Sooner or later, the market will correct problems with commercial applications. Modest, modular commercial applications will replace immodest, bloated ones. This will be increasingly clear as we move into 1998. But internally developed applications also suffer from immodesty problems. And the fully loaded cost of immodest internally developed applications can be quite high. This often begins with a specification document that grows so large and so complex that no one really understands what should emerge. Certainly, no user understands, and it often seems that no developer does either.

There are a number of different costs that come along with immodest internal applications. The cost to develop the application is high. The cost to document the application is high. It takes too long to train users, and they never seem to master the application. Modifications, even simple ones, take too long, are too costly, and are too dangerous. In today's information intensive world, the organization which finds a way to build modest internal applications will have significant cost and flexibility advantages.

The problem starts as the specifications are being developed. Users often feel that they will have only one opportunity to get everything they need. If it isn't requested, now, several years could go by before they have a chance to request additional features. Users can also suffer from the forest-and-trees syndrome: they can't see the overall pattern of what they are requesting because they get lost in all of the details that seem so important. It can be the classic case of being unable to see the forest because all the trees get in the way.

On one level, users should not be expected to see the overall patterns which could be used to simplify the requested system. After all, the ability to identify overall patterns is not a skill that is important for the jobs performed by many users. The systems people, however, ought to be able to see overall patterns, even in the midst of conflicting details.

There is a natural flow in the analysis of a problem or opportunity. At first blush, it seems simple enough. The user wants a system to help them count widgets in the factory. But then the complexities being to roll in. Some widgets are purchased and some are manufactured internally. Widgets come in a wide array of colors and sizes, with costs that vary equally widely. For certain kinds of widgets, smooth operations in the factory critically depend on having a ready supply. Any outage can be expensive. And finally, different kinds of widgets age differently. Some widgets have a shelf life that is practically infinite, others have a shelf life measured in days.

After the first conversations about widgets, the simple request become incredibly complex. And that's where too many systems people leave it. They don't struggle to find "the simplicity on the other side of complexity". There really are only three basic kinds of widgets. And most of the information about the different kinds of widgets can be adequately represented in the text description that accompanies each of the many detailed options. Systems people will not generally be rewarded for discovering the basic simplicity in the problem or opportunity. Indeed, their productivity can go down if they reduce the size of the specification.

Perhaps more fundamental, it seems that only a minority of people are driven by a desire to find deep simplicity in the midst of apparent complexity. Such people are rare in the general population, and do not seem to occur much more frequently in the ranks of the systems people.

Simplifying Tactics

Two specific tactics have been useful in encouraging greater simplicity in internally developed applications.

Planned Versions

One useful tactic to reduce the pressure to get everything into the initial system is to publish a schedule of planned subsequent versions. All important systems will go through multiple versions. Publish the schedule of new versions, up front, and the participants see they will have an opportunity in the near future of add any important missing features. It can be a liberating experience for users, and for developers, to recognize they are only working on version 1.0, and there will be a version 2.0 within 12 months. This tactic has the important fringe benefit that it reduces the impact of the Uncertainty Principle for Systems.

All of this makes great logical sense, but can run into problems with the normal way of cost justifying new systems. In the traditional approach, there is a cost to developing a new system, and an expected benefit. To justify a stream of new versions, it is necessary to build a model for a cost stream with a balancing benefit stream. That kind of model can be more difficult to build, and to explain. Not every organization is prepared to listen. There is, fortunately, a reduced form of this tactic which can be applied in many circumstances.

Set an intermediate target of a basic complete operating version of the system to be delivered for no more than 66% of the total development budget. Refinements will be missing from this initial or intermediate version, but all the basics should be in place and operating. If everyone works to this intermediate target, the result is more likely to be a modest system. The remaining 34% of the budget can then be used to add features that are really important.

Market Orientation

Something positive can happen when the developer works to satisfy a market rather than a particular user. In the traditional approach, there was someone with the authority to "sign" for the user. The developer need only respond to the requests from that authorized user. This absolves the developer from any responsibility for efficient or effective performance after the system is installed. It's a simple black-and-white picture that often ill-serves the organization, the user, and the developer.

It is often more accurate to view the process as one in which the developer builds a product to be released into the internal market. The critical difference is that the developer's goal is a product that will sell within the organization. This shift in perspective can be quite liberating. The developer gets the opportunity to do it properly, but tempered by the need to have a product that can be sold to the market of prospective internal users. This forces the kind of approach that is most likely to produce modest systems.

If the resulting product is simple, easy to explain, easy to learn, and easy to use, then the internal market will respond with its approval. Let it be complex, difficult to explain, learn, or use and that same internal market will withhold its approval. The largest problem with this market oriented approach is that it breaks many of the traditional controls around systems development projects. No one has "signed" for the system before work begins. The organization is acting almost like an investor who is speculating about what the market will accept.

Future Prospects

The market for commercial applications is driving vendors in the modest tools direction. 1997 is likely to be the end of the line for evermore bloated new versions, especially of the more popular office applications. We should encourage modest software tool vendors with the approval that is most important - our purchasing dollars.

At the same time, organizations should search for ways to encourage the internal development of modest software tools. The two tactics sketched in this article are only two of many possibilities. The required talent may not be wide-spread, but we should do everything practical to encourage its application. We need systems people who will fight for the simplicity on the other side of complexity.


back to interests


¹Reprinted with permission from Information Strategy, Volume 14, Issue #3, Spring, 1998, pp. 44-48. Copyright Auerbach Publications, an imprint of CRC Press, Baca Raton, Florida, 1998.