In this installment of the Quality busters series, I'll look at an aspect of application efficiency. Application efficiency deals with how well an application performs and assists users with their intended tasks. The Quality busters series does not present a single solution to the problems it considers, but shows that addressing operational and nonfunctional requirements involves making tradeoffs between many solutions, none of which is ideal.
"It only shows a grey window!"
The sales managers complained that using the Web-based forms to update commission and pricing information was slow and awkward. They spent over two days each month to update this information, and that was not acceptable. The SHEEP team decided, for various reasons, to build a traditional GUI fat client using C/C++ to implement the commission and pricing update functions. The team called this client LAMB. The same functionality was still available through the Web-based forms.
Development and testing proceeded quickly. The representatives from the sales manager community were pleased with the results and their hands-on work in the test lab. Everyone was happy and gave the go-ahead to deploy the LAMB software to the 30 sales managers.
Soon, however the SHEEP team received a call from the sales director. She complained that every time she tried to start the LAMB program, all she saw on her screen was a grey window. One of the developers went to her office to investigate. He discovered that the director was using an older system, which still ran Windows 98 and had very little memory; the director often had several applications running on this system at the same time. When the LAMB software started, it used up the few remaining system resources and only got as far as clearing the window before hanging.
The director's system was already scheduled to be upgraded in a month, so the SHEEP team worked with operations to upgrade it sooner. Once the system was upgraded, the LAMB software worked fine.
After the problem was resolved, the SHEEP team met to identify what went wrong and what they could do better. First, they discovered that they had assumed that everyone was running hardware and software similar to the systems in the development and testing groups. Secondly, they discovered that the LAMB program was distributed with code compiled in debug mode; thus, it was larger than necessary and used an excessive amount of system resources. Finally, they discovered that the program did not adequately check for system resources and prerequisites, thus allowing it to fail or hang.
The first lesson learned was that not everyone in the corporate environment shares the same hardware and software as developers. Often, developers have more up-to-date equipment, such as larger hard disks, more memory, and faster CPUs. These are usually required due to the heavy resource demands of modern development tools. End users may have systems that are several years old and have just enough resources to support office suites and Web browsers. To complicate matters, many users in corporate environments use personal equipment to work from home or from customer locations. While corporate standards try to minimize the number of variations that exist, they don't always eliminate variants.
When developers are isolated from the end user community and only run the applications that they write on their powerful systems, they develop the false idea that everyone's computer is equipped similarly to their own. To generalize experiences and extend them into the unknown domains is a simple human trait; much like the naïve American tourist who thinks that everyone in Japan will speak English simply because he does.
Some symptoms of myopia in application code include:
- Bloated programs might be a symptom of assuming large or nearly unlimited disk resources. The program provides a large number of components and files, many of which may already exist on the client system.
- Slow-loading programs might be a symptom of assuming large memory resources and assuming that the user will use all features of the application every time it is run. Loading many components at startup speeds later operations. But sometimes deferred loading of components is better, as it reduces memory requirements.
- Slow-running programs might be a symptom of assuming a fast CPU. Sometimes, code based on inefficient algorithms can seem fast enough when run on a speedy processor. But, on a slow CPU, the inefficiencies become readily apparent.
To correct this myopia is a little more involved than buying eye glasses. It involves developing an end user point of view. You might improve developer awareness of users in several ways:
- Testing time. The developer spends time with the testers or performs end user acceptance testing.
- Field assistance. The developer works with representatives from the user community at the users' work location. Usually this occurs when the user reports a problem. Thus, developers can experience the application's usage first-hand.
- Help desk. The developer spends some time on the help desk responding to user problems with the application.
- Field trips. Even without a problem to be resolved, developers can learn a lot about their corporate environment by simply venturing outside the IT department.
- Performance training. Many books and resources about creating optimally performing applications and selecting algorithms are available. A department policy might be established that encourages developers to learn methods and techniques that improve program performance.
The second lesson learned was to be careful about distributing into production programs that have leftovers from the development process. In this case, the SHEEP team released into production a program that had all the debugging and tracing logic active and intact. While this was helpful during development, it caused resource problems on user systems.
A well-designed program provides informative error messages to users. (I discussed meaningful error messages in a previous article in this series; see Resources.) A program released to production users should not deploy debugging, tracing, and monitoring components. If users have a problem that does require such facilities, it is usually easier in a corporate setting to release these components when needed to help with diagnostics and remove them when finished.
Developers may think that end users have adequate resources to handle the leftovers. They may also choose to release debugging, tracing, and monitoring components intact on the chance they will need them to diagnose a problem.
Correcting leftovers requires diligence by the project manager and software configuration management team. Some possible ways to do this include:
- Release review. The release process might include steps to check the program and deployment package to ensure that development leftovers were removed.
- Platform testing. Extend the test environment to include a wider range of target platforms that represent the user systems. This includes having a system that represents the least powerful configured system to be used by the end user community.
The final lesson learned was to not be presumptuous about the runtime environment. The LAMB program assumed that all the resources it needed were always going to be available. This included memory, disk, and, in the case of Windows 98, entries in the system resources table. As a result, the program did not test the condition of any of these resources before starting. Then, when a resource wasn't available, the program simply hung or failed.
Correcting presumption is the easiest of the three problems I discuss in this article. It involves writing code that tests to see if adequate resources are available before continuing an operation. When resources are not available, the application should present a meaningful error message to the user.
Ideally, development can capture end user problems during acceptance testing, before the program is released. The problem is that most corporations do not create a testing department that has representative systems corresponding to every combination of hardware and software in use. It is too expensive to allocate so many resources and keep all the test systems refreshed. Also, the time it takes to test code on all these systems is excessive and not responsive to end user requests. A compromise is to have a few representative systems, configured with the minimal resources known to be in use.
Many companies establish corporate-wide standards that dictate the hardware and operating systems that IT will support. While these standards can have a positive effect in the purchasing and technical support departments, they do not always reflect the reality of the systems in use. Often, a company acquires systems by means that bypass such standards; for instance, during a corporate merger, acquired systems might be grandfathered in.
Standardized hardware and operating systems, while a good thing, does not necessarily help software developers. The temptation is to write programs specifically for those systems. Then, when the next generation of hardware and operating systems start to arrive, the programs might suddenly fail for various reasons.
If developers instead concentrate on software standards, they increase the number of systems that their code will support. For example, more systems support programs written in standard C or the Java language without using compiler-specific extensions. The majority of browsers support Web pages coded to the W3C XHTML and CSS standards rather than to browser-specific extensions. In this way, developers no longer need to worry about supporting a wide range of systems; rather, the burden is on the browser or the operating system vendor to support the various standards.
When you create applications, remember that everyone's environment is not the same. Be sure that the architect and project manager ask and get answers to these questions (among others):
- Is the application made of more components than are really necessary to support the user's task?
- Does the application preload more components than the average user actually uses? Can the loading of those components be deferred until they are actually used?
- Is the program slow because it is based on inefficient algorithms?
- Is it possible to build a user perspective among developers by involving them with the user community?
- Do developers participate in user acceptance testing of a release?
- Do reviews of deployment packages ensure the removal of development artifacts that are not needed in production?
- Has the application been tested on minimally configured systems representative of those in the user community?
- Has the program been written by following available standards?
- Does operations or technical support maintain an inventory of the user community's systems?
When IT development is isolated from the user community, developers easily can think that users have systems similar to their own. This form of myopia can result in programs that are bloated, slow to load, and slow to run. Some of the bloated size can be a result of development leftovers, such as debugging and tracing components. Finally, since developers often have far more powerful systems than users, developers may assume that users have nearly unlimited resources. All of these factors can result in an application that is large, slow, and prone to failure. One solution is to develop better user awareness.
- Read the author's other articles in the Quality busters series on developerWorks.
- Extend the techniques in Preventative Programming Techniques: Avoid and Correct Common Mistakes, by Brian Hawkins, beyond coding errors to the overall development process (Charles River Media, 2003).
- Read this great source of information about the people side of software, The Peopleware Papers by Larry Constantine (Prentice Hall, 2001).
- Explore high-level software team organization topics in Debugging the Development Process by Stephen Maguire (Microsoft Press, 1994).
- If you evaluate the business aspects of the technology lifecycle and tools to optimize technology change, check out this good guide for managers and architects: Managing Systems Migrations and Upgrades, by Charles Breakfield and Roxanne Burkey (Butterworth-Heinemann, 2002).
- In Anticipating Change by Gerald Weinberg, learn to create a supportive environment for handling the chaos of change (Dorset House, 1997).
- Visit these valuable resources on the IBM developerWorks site:
- The developerWorks Web Architecture zone specializes in articles covering various Web-based solutions.
- Browse for books on these and other technical topics.
Michael Russell has a bachelor's degree in physics and a master's degree in computer science. He was a logistics engineer, a technical services manager, and a certified IT architect at IBM for nearly 14 years. He is currently a Web application architect for a resort company in Orlando. He has experience in Windows, UNIX, and OS/400 environments. He uses Web technology for entertainment through his own company, Vicki Fox Productions (http://www.VickiFox.com).
Table of contents
Tags
Use the slider bar to see more or fewer tags.
For articles in technology zones (such as Java technology, Linux, Open source, XML), Popular tags shows the top tags for all technology zones. For articles in product zones (such as Info Mgmt, Rational, WebSphere), Popular tags shows the top tags for just that product zone.
For articles in technology zones (such as Java technology, Linux, Open source, XML), My tags shows your tags for all technology zones. For articles in product zones (such as Info Mgmt, Rational, WebSphere), My tags shows your tags for just that product zone.
Popular article tags |
My article tagsSkip to tags list
Popular article tags |
My article tags