DBMS, August 1996
Will the wonders of the Web never cease? Vendors are starting to tell me that their products support the development of temporary applications. People have built temporary applications to support short-lived, nonrecurring events such as natural or man-made disasters and special marketing campaigns for quite some time, but the Web promises to usher in the era of disposable development on a large scale.
Vendors of tools that are used to build dynamic Web sites and applications equate static Web pages with a mortal plague to be avoided at all costs. The message I get is that not only must the content be database-driven, but users must be treated to new thrills on a frequent basis.
This drive for constant freshness and variety overlooks an important distinction. In an electronic commerce system, one part is primarily information publishing (the marketing function), and another part captures transactions (order taking). Online catalogs, with forms that let users purchase products, perform both functions.
This distinction is critical because you cannot apply the same mindset to both the presentation and transactional aspects of a Web site. The marketing function of a Web application needs regular redesigns to maintain a fresh look. However, these designs must retain a family resemblance so that users don't feel lost or confused. The printed L.L. Bean and Lands' End catalogs change often, but you can recognize and distinguish each one at a glance. Applying the same visual turnover to the transactional interface in a Web application can backfire quite quickly. To facilitate a purchase, the last thing you want is for customers to spend time figuring out what changed from the last time they placed an order and how to do it this time. The transactional interface should not only be stable across time, it should be consistent within your site if the application contains multiple order forms.
Terms like "Web weeks" or "Web years" epitomize the highly compressed time frames currently affecting Internet product life cycles. Now, this compression threatens to spill over into the application development life cycle. As more end users see Web applications changing as fast as department store display windows, some will ask MIS why it takes so long to build applications for their departments. Adopting Web browser interfaces for more and more corporate applications will intensify the all-too-familiar pressure to deliver applications faster.
How do you cope in a world like this? I believe there are at least two guiding principles that offer some hope. First, shorten your development cycle. Second, write and use more reusable code and make this the mantra guiding your development efforts. The two strategies are complementary.
Development life cycles are often described as either linear ("waterfall") or iterative. Perhaps more attention should be paid to parallelizing development work. Working on more tasks simultaneously can shorten the overall development effort. Review your project plan and identify tasks that can be partitioned off the critical path. This may require a more horizontal staffing model based on larger teams that coalesce for shorter periods of time. It may also help to package your application deliverables in smaller pieces so they can be built, deployed, and even replaced faster. Component development promises to accelerate application construction and to increase reuse. Many components released so far have been relatively simple controls for forms. The next stage is to package small cohesive units of business application functionality as components that can be added into several applications with a minimum of fuss. In addition to horizontal (generic) controls, future components will perform vertical or industry-specific, or even company-specific, tasks such as calculating an insurance premium.
The proliferation of public "beta" software may be a trend corporate developers can turn to their advantage. If users begin to accept pre-production software for everyday tasks, perhaps you can experiment with early releases of Intranet applications that you develop. Warn users to expect higher defect rates, and don't try this with "bet the business" applications, but for many projects, riding this trend might let you deliver software more quickly.
Reconciling an era of disposable development with large-scale applications will not be easy. Many companies using client/ server technology have progressed past the workgroup application stage and are now building bigger enterprise-class systems. Meanwhile, the Web is influencing both developer and user expectations for faster results. As the shelf life of an application shortens, a significant portion of your time, effort, and money will be thrown away in the near future. Hang on - this will be a wild ride.
