Government Technology

Future-Proofing Applications

April 23, 2009 By

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

| More


Add Your Comment

You are solely responsible for the content of your comments. We reserve the right to remove comments that are considered profane, vulgar, obscene, factually inaccurate, off-topic, or considered a personal attack.

In Our Library

White Papers | Exclusives Reports | Webinar Archives | Best Practices and Case Studies
Public Safety 2019
Motorola conducted an industry survey on the latest trends in public safety communications. The results provide an outlook of what technology is in store for your agency in the next five years. Download the results to gain this valuable insight.
Improving Emergency Response with Digital Communications
Saginaw County, Mich., increases interoperability, communication and collaboration with a digital voice and data network, as well as modern computer-aided dispatch.
Reduce Talk Time in Your Support Center by 40%
As the amount of information available to citizens and employees grows each year, so do customer expectations for efficient service. Contextual Knowledge makes information easy to find, dropping resolution times and skyrocketing satisfaction.
View All

Featured Papers