Future-Proofing Applications

If you have a one-time only task that entails some kind of repetitive work, don't give it to a developer.

by / April 23, 2009

In the halcyon days of glass rooms and mainframes, application development was a logical, step-by-step, paced process. It involved careful specification of everything from the database to input screens. Many of us can remember the shelves full of binders containing detailed specs covering everything related to an application -- the planning alone might occur over a period of months or even years.

Application development followed a logical, sensible course. Projects started, they were planned, laid out carefully, built and deployed in a nice, relatively neat linear progression that at least from the viewpoint of the end users took a long time.

All this orderliness encountered the ultimate apple cart upsetters: cheaper computers in the hands of pesky and impatient end users. And, if that wasn't bad enough, the Web arrived which somehow seemed to turn anyone with access to a keyboard and an ability to type into "developers."

Although the Web became -- and still is to a large extent -- a wild west, the fact remains that building good, solid, enterprise-worthy applications depend on many of the solid principles that ruled the glass rooms.

But, even when sound development principles are in use, things still need to move at Internet speed and flexibility is far more important than it used to be. As computing power increased and Web application development matured, some interesting approaches have emerged to reconcile the need for well-planned applications and the flexibility required to survive in the rapidly changing world of the Web.

A popular book written in the infancy of the Web began with a description of what makes a good programmer -- a memorable item from that list was the assertion that developers are "lazy." The author goes on to clarify that this doesn't mean they don't work hard but that by doing things right and writing applications to automate routine or boring jobs, developers buy downtime.

Perhaps another way of saying it is that good developers never want to do the same thing twice. They would rather spend a long week of late nights writing a program to empower a non-technical user to easily import a set of records than to spend a mindless week doing repetitive data entry themselves.

So, the rule is that if you have a one-time only task that entails some kind of repetitive task, don't give it to a developer: chances are good they'll spend the full schedule and then some developing a program to do automatically what could have been done faster by hand. Of course, their argument is that the second time the same task needs to be done, you've recouped the investment.

The old way of building applications -- whether for the glass room or the Web -- was to talk with the end users to identify the "things" the application needed to manage, what "actions" needed to be done with those "things" and what kinds of "outputs" were required.

Based on this data, a database was designed and built to store the "things", code was written to present screens by which the end user could enter, edit or delete the "things," more code was written to perform "actions" on the "things" and, finally, reports and output routines were written to send the "things" somewhere else.

A simple example would be an application to manage employees and their HR benefits. The employees and benefits are the "things;" signing up for or canceling benefits are some "actions" and reports to management or interfaces to a payroll system would be the "outputs."

Pretty straightforward and pretty flat.

When different or new information needed to be added about employees, a developer generally needed to do the following:

1) Update the database to hold the additional data.
2) Change the enter/edit

forms to accommodate the new fields of info.
3) Change the code that does the actions so it takes the new data into account.
4) Update the outputs to accommodate the new information.

Developers got tired of some of these actions, specifically:

1) Updating databases to accommodate more data.
2) Changing forms to add new fields.
3) Changing existing code to accommodate new information.
4) Updating outputs to accommodate new data.

In short, they didn't want to do any of it as it violated their aversion to doing the same thing twice.

So, instead of building a form for entering or changing data, the developer writes a mini-application whose job it is to find out what kind of information needs to be on the form and then, using that data, the application builds the form itself.

This results in an application whose job it is to build another application, i.e. the actual application accessed by end-users.

This gets a little trickier when it comes to building the database. Instead of just building a database to hold information about an employee, the developer builds a database that holds a list of the kinds of information that need to be stored about an employee and then writes code to use that information to figure out how to store the actual data. The database itself stores the real data in some generic way that the developer doesn't need to bother about.

For example, such an employee database would store a list of the kinds of data needed about an employee: first name, last name, Social Security number, address, salary etc. When a new kind of information needs to be added, it is added to the list and the application takes care of working out how to store it.

So, if later the company issues ID cards with new, unique numbers, someone adds the ID card number as a type of data to store and the application takes care of updating the database (and the entry forms, reports etc.) automatically. In the old days adding this kind of information would have required a manually implemented database change (not to mention all the changes to forms and business logic).

Here again we have an application whose basic job is to update or change an existing application (or database in this case) -- an application that builds applications.

In fact, this approach has been in use for years in various forms but it is becoming more prevalent in Web applications and an increasing number of tools exist to help developers build applications this way.

Because of its prevalence, it is important for business people -- who are asking for the applications in the first place -- to understand the basic idea and the ramifications of this approach because is it not right for all applications. Following are some aspects of this approach important to business users:

  • Requirements. During the requirements gathering, it is not enough to just talk about the specific "things" the application needs to manage; the developer will also be interested in the kinds of things it might need to manage. For example, instead of just talking about the specific data fields related to employees, developers might want to talk about what kinds of data are important as related to people in general.
  • The future. In addition to talking about what is needed right now, the requirements need to address the future -- specifically what kinds of changes are anticipated in the application over time and how often those changes are likely to occur. For example, if the organization has used the same definition for an employee for 20 years without ever having to store new kinds of information, then employee data could probably

  • be stored more statically. However, smart developers will always challenge statements that something "will never change" because experience shows they usually do.On the other hand, if you anticipate that new kinds of benefits will emerge in the future, this would obviously be an area that needs to accommodate change -- ideally with little to no developer involvement.
  • Complexity/Flexibility. It is more complicated to build applications that build applications -- the simplicity for users and flexibility they offer is "purchased" with additional complexity for the developer. This can impact the budget and schedule but can pay off in the long run. It also means that such applications usually require more highly skilled developers.
  • Cost. Upfront costs are higher in part due to the greater application complexity but since industry figures show that far more than 50 percent of an application's overall cost is in maintenance, in the right situation this approach can make a lot of sense. The "right situation" needs to be determined on a case-by-case basis which consists of an evaluation of how much change will be required over time. If the application will never change over the next 10 years, it doesn't make sense to build in the flexibility of an application-building application. But, since reality is that almost no applications remains static for any length of time, it is important not to take a static state for granted.
  • Performance. Building application-building applications can have performance impacts so they tend to be more appropriate for internal applications or administrative applications. However, intelligently planned, such applications can perform well -- but it is important to spend time identifying the exact performance needs and identifying any potential problems.

This kind of approach to application development is not new and it manifests in many forms -- the high degree of customization possible on some Web sites is an example of this kind of thinking -- and it is becoming more common, particularly when talking about Web applications.

This becomes important for agency heads to understand when specifying solutions because their developers should be looking beyond the immediate problem and trying to solve problems and anticipate needs that haven't yet occurred. This can save money in the long run and also may be a factor in user satisfaction because end users are beginning to demand flexibility in their web applications -- they have a fading patience for applications that can't be updated quickly to meet shifting needs.

Getting away from static applications that lock an agency into functionality that is hard to change can be overcome by building applications that build applications. And doing so can have the additional benefit of getting developers to work like mad while appealing to their basic laziness.

David Aden
David Aden is a writer from Washington, D.C.