Avoid developing in a bubble

Programmers tend to live, or at least work, in a perfect world. As a network engineer and a software developer, I am amazed at the number of applications developed in a bubble—a near-perfect, sterile development environment that does not match the environment for which the application is being built. Applications developed in this bubble tend to perform poorly when ported to the target environment. I call it the “Hey—how come this application’s so slow; do you think it’s the network?” syndrome. (I realize this is an unusually wordy name, but it readily identifies a common, post-implementation dilemma.) Typically, the lack of performance is symptomatic of disparities between the development environment and the real-world environment. Developers need powerful CPUs and robust networks to build today’s complex applications; the target user, on the other hand, has a completely different set of IT requirements. Developers must be careful not to lose sight of the target environment or its constraints.

Assuming you are about to undertake a new development effort, what can you do to ensure that you do not develop in a bubble? This article outlines some steps to follow.

Factoring in bandwidth constraints
Many performance problems can be avoided by factoring in bandwidth constraints during the design phase. If bandwidth constraints are not accounted for in the system design, the effort will yield a barely usable application; the development team will spend an exorbitant amount of time re-engineering the application; and management will struggle with attempting to justify the application's inadequate performance, as well as the project's cost overruns and schedule slips. I have been called into many meetings and asked, “What's the problem, and how can we fix this?” My typical response is, “It’s going to take a lot of time and a lot of money,” and it usually does. It is always more beneficial (and cost effective) to factor network constraints into the design at the beginning of the project, rather than trying to meet the bandwidth constraints after the product has been built.

A good example is my company’s timesheet program. This application was well designed, and well thought out, at least from a timekeeping perspective—but not from a system perspective. The program itself is intuitive, but it is barely usable because of how slowly the screens load. Given the severity of the performance problems, I was amazed to discover that they were completely unforeseen during development and testing. How could performance problems of this magnitude have gone unforeseen and undetected until implementation?

The culprit was the sum of the differences between the target and development environments. Although the timesheet program was primarily designed to exchange data either across the public Internet or a closed Wide Area Network (WAN), it was developed and tested exclusively on a local area network (LAN). The database engineers designed the database around the timesheet data and normalized for maximum efficiency across the company's closed LAN. The software engineers built the application to pull multiple rows at a time from the database (rather than build views containing only the necessary data elements), without considering the implications to network availability because there was ample bandwidth on the LAN. During testing, the application easily exceeded minimum performance requirements, but during implementation—much to everyone’s surprise—the program suddenly ran incredibly slowly.

Having looked at the bandwidth requirements, post-implementation, our only option was to upgrade our connection to the Internet—thereby increasing the available bandwidth. As one of my coworkers quipped, “And where do we log the hours spent trying to log into the timesheet program until the network is upgraded?”

To avoid such bubble-induced problems, you must begin by identifying anticipated bandwidth requirements and known bandwidth constraints. The following steps below will help you avoid the bubble trap.

Ask questions about the target infrastructure
Remember that your purpose is to identify bandwidth constraints. As a minimum, be sure to ask the following questions about the target infrastructure:

What is low, average, and peak network utilization at key points in the infrastructure?

How many users (of the system) will there be on each segment?

Are any equipment or circuit changes planned (upgrades, downgrades, and so on)?

If this is a client-server application, where will the server be located: on the WAN or on the LAN? If a WAN will be utilized, what is the size of connection to the WAN?

What is the network’s primary function: office automation (e-mail, file sharing, printing), or multimedia (streaming audio, streaming video)?

Is there a firewall between client and server? And if so, are the necessary ports open?

Project your application’s bandwidth requirements
Take a careful look at the design, and project your bandwidth requirements. For data-centric applications, which account for the majority of the applications being developed, bandwidth requirements will center around average record sizes, types and frequencies of queries (number of records returned, inner joins versus outer joins, and so on), and the amount of data being returned to the client.

Analyze your requirements
Armed with the information from the previous steps, analyze the requirements. If a disparity exists between the two, include it in your feasibility study. If the bandwidth requirements do not match the bandwidth constraints, this difference should be identified as a potential ”infeasibility.”

Build a model target environment
Finally, build a small model of the target environment for gauging performance, especially if the application is designed to use a WAN or exchange data across the Internet. Contrary to popular belief, setting up a mock WAN or mini-Internet does not require a lot of time or expensive equipment.

Let’s refer back to the timesheet program described earlier. The developers could have set up a router and throttled the available bandwidth to the target's typical wide area connection rate. By inserting an inexpensive router (one that supports throttling—for example, the Cisco 1601) between the client and the server, the target environment could have been modeled easily. Using this miniature WAN, performance problems can be identified during the early stages of the development effort.

Conclusion
It is easy to avoid the trap of developing software in a bubble. A little time invested in preliminary analysis (such as matching the target constraints against the bandwidth requirements before development begins) will save countless dollars, time, and heartache in post-implementation redesign. When it comes to software development, the old adage is true: “An ounce of prevention is worth a pound of cure.”