In Chapter 1, I defined component software as the practical and consumer-oriented realization of the developer-oriented principle of object-oriented programming. I described the benefits merely as the capability to add features to applications by purchasing components rather than by purchasing entirely new builds of feature-laden monolithic applications. In other words, instead of necessarily purchasing applications, end users would build their own custom applications to solve their own specific problems.
Why is this important? Think for a moment about how applications—the tools that are used to solve problems—are built today. A software vendor decides to create an application for a particular market segment. Designers from the company then use a variety of data gathering techniques to determine what problems need to be solved and what sorts of tools people would like to use to solve those problems. They send out surveys, hold focus groups, create and test prototype software, and so on. Eventually this data is collected and brought together in a functional specification. This specification drives the development of the software and, after a number of months or perhaps years, the software is fully developed and tested, ready to be sold in the software market in which people will generally purchase that release for the next year or two.
While this process is accepted as the standard today, look at the problems that are inherent in it. First, the data collected from surveys and similar methods depends greatly on the ability of target users to articulate exactly what they want. In other words, these collection methods assume that customers know what problems they want to solve and can articulate what those problems are as well as potential solutions. This is almost never a valid assumption, however, so it requires extremely careful design of surveys and other material (which has led to colleges offering degree programs in survey design). But no matter how you ask your target users what they want, they may or may not be able to articulate exactly what it is they need. And we all know, on a personal level, that what we say we want is not necessarily what we really do need. (For example, you say you want a sports car, but what you really need is basic transportation.)
So because data gathering techniques do not necessarily yield the correct data, applications built from that data will not necessarily solve the problems they intended to in the first place. Let's say, however, that such methods did yield the correct information (which is possible, simply unlikely). From the time a software development team receives this information to the time it can realistically deploy a solution is on the order of 3 to 6 months, minimum, even in a corporate setting. This reveals the second major shortcoming of our current design methods: by the time most software solutions are deployed, the problems that they intended to solve have most likely changed or become irrelevant. This is even more true when software is developed as a retail package and then sold for 18 to 24 months afterward. The problems addressed by the software at the end of its production cycle may already be 3 years old.
The most significant result of both the data gathering problems and the lag in deployment is that applications become more and more general purpose: single applications are designed to solve a wide variety of problems. Take, for example, Microsoft Office, which is composed of Microsoft Word, Excel, PowerPoint, Access, and Mail. Office is already sold as if it were a single product, and the integration capabilities provided through OLE blur the boundaries between the various pieces of Office.
This is not to say that general purpose tools are useless. In fact, they are very powerful and do many things that were not available in the past. But they have a hidden cost—user training. The more general purpose a tool becomes, the more training is necessary for users to learn how to apply that general tool to their specific problems. This is why there is still so much said about user-friendly applications and usability. This is why course catalogs for community colleges are littered with classes on using this or that application. This is why bookstores devote large amounts of shelf space to books that focus on using a specific application. The purpose of these after-market products is to help end users understand how to use general purpose tools to solve their specific problems.
But is this really what application software should be? After all, there is nothing sacred about our current software production methods. When I first used a computer, I didn't have any shrink-wrapped software at all—when I had a problem to solve, I sat down and wrote a program to solve it. If my first attempt at the program didn't solve my problem, I modified the program and tried again, until I got it right. When the problem was solved, I either dumped the program or saved it in case I might have a similar problem in the future and could modify the existing program to help solve it. Now, it occurred to a few people that other computer users might be willing to pay for a software solution, and this spawned the growth of the shrink-wrapped software industry, which has led to general purpose tools.
So what does all this have to do with component software? I believe that component software is the technological innovation that will spark a new explosion of growth in the software industry by empowering computer users to once again create their own custom applications for their own specific problems. In the future, using a computer will not entail starting an application but rather spending one or two minutes creating an application for whatever problem is at hand. This does not mean that end users will be writing C code—absolutely not! Instead, they will have high-level tools through which they can specify their exact problem—that is, specify their intentions. These tools will then assemble a solution—a very specific application—from a large pool of available components. If the application is not the perfect solution for the user's problem, the user can quickly modify it, again using a high-level tool, until it does solve the problem. Even when users don't fully articulate the problem initially, they can quickly go back and clarify their intentions. Within minutes, I believe, users will always end up with the right solution.
The result of this iterative problem-solving environment is that end users get exactly the applications they need exactly when they need them. In other words, a component software environment with appropriate high-level tools is one that avoids the problems of our current software development process. First, we eliminate the inaccuracies inherent in surveys, focus groups, and other data collection schemes. We also avoid misinterpretations by human beings trying to take all that data and formulate a functional specification, which is then subject to misinterpretation by a development team. Component software eliminates these processes by giving immediate feedback to users to tell them whether their stated problem was, in fact, their real problem. Second, component software eliminates the minimum 3-to-6-month lag between a user specifying a problem and a software solution being delivered. In the picture I'm painting here, a user specifies his or her intentions to a high-level tool that then cranks out an application within minutes.
Users are smart people. They know what problems they have to solve, but they are continually frustrated by their inability to articulate these problems to today's general purpose applications. Applications should solve problems, not simply be a tool to create solutions to problems. And most important, applications should not be problems themselves!
The future I see for component software is that given enough components and the appropriate types of tools to integrate those components, any end user will be able to sit down at a computer and quickly create a custom application for a specific problem—an application with all the power available in today's commercial applications. In the future, using a computer will mean stating problems and intentions and having the computer generate and execute a solution.