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

Comments

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
Cybersecurity in an "All-IP World" Are You Prepared?
In a recent survey conducted by Public CIO, over 125 respondents shared how they protect their environments from cyber threats and the challenges they see in an all-IP world. Read how your cybersecurity strategies and attitudes compare with your peers.
Maintain Your IT Budget with Consistent Compliance Practices
Between the demands of meeting federal IT compliance mandates, increasing cybersecurity threats, and ever-shrinking budgets, it’s not uncommon for routine maintenance tasks to slip among state and local government IT departments. If it’s been months, or even only days, since you have maintained your systems, your agency may not be prepared for a compliance audit—and that could have severe financial consequences. Regardless of your mission, consistent systems keep your data secure, your age
Best Practice Guide for Cloud and As-A-Service Procurements
While technology service options for government continue to evolve, procurement processes and policies have remained firmly rooted in practices that are no longer effective. This guide, built upon the collaborative work of state and local government and industry executives, outlines and explains the changes needed for more flexible and agile procurement processes.
View All

Featured Papers