If you build a house, do you nail together the walls before you figure out where to put the bathroom? Common sense says this house won't meet the needs of its owners. Unfortunately, many client/server developers and application architects take this approach when they build an application. Their client/server development tool often serves as the design tool, the requirements repository, and the application incubator.
Today we are tool-rich and design-poor. Why? I'm sure media hype has something to do with it, as well as vendor evangelists who stress Rapid Application Development (RAD). We seem to rely more and more on development tools, and everyone searches for that next "silver bullet." Even more so than in the past, both client/server and Net development tool vendors are pitching their products as means of compressing the development lifecycle.
If you listen to the hype, RAD was and is a silver bullet for application design, development, and deployment. RAD promises to finally free us from the boring process of learning business requirements, data modeling, and designing application object hierarchies. RAD is an interactive effort, so promoters tell us we have no need to deal with a rigorous application development life cycle. It's something you'd hear on a late-night infomercial.
Sorry to be the bearer of bad tidings, but the reality is not that exhilarating. Sound client/server applications demand that everyone understand both the business requirements in detail and the business problem to be solved. This means you have to cancel your subscription to the tool-of-the month club, dust off the drawing board, and get to work. You must do your homework, too. RAD is just a component of the application development life cycle, not the life cycle itself.
"Who did the system design?" I always ask.
"What design?" is the general response. "We're using RAD."
Don't take me there! RAD is a good fit for simple application-development efforts with bite-size requirements. RAD is not a good fit for complex client/server application development. Most client/server projects that last over a month fall in the complex range. However, RAD is a powerful tool to use in conjunction with a rigorous application design process.
There are three things to remember when using RAD. First, RAD only works when you understand the business problem that the application must solve. Second, RAD should not be tool-driven or tool-dependent. Finally, RAD is only effective when it's a part of a sound application development process.
As technical professionals, we tend to focus on the technology and avoid the business issues at hand. The fact is, if we neglect to understand the business problems we need to solve, there's little chance that we'll get the system right the first time. Information you need to acquire includes the business purpose of the system, the inputs and outputs, the type of system (transaction processing, occasional use, decision support, reporting, and so on), and all of the legacy and new data sources that need to feed the application. If you don't get this right, you can't get anything else right.
Although selecting the right tool set for your client/server development project is always helpful, the tool should not drive the architecture or the design. It should be the other way around: The requirements drive the architecture and design, and the architecture and design drive the tool.
Some client/server development organizations are moving to the strict Software Engineering Institute (SEI) Capability Maturity Model (CMM). The CMM uses five levels to reflect the development organization's process maturity. You have to fill out a 100-point questionnaire to determine your level, which you should do to find out just where you are -- kind of like a yearly physical.
On one level you'll find organizations with random or chaotic processes using ad hoc management of the application development effort. The vast majority of client/server systems are built in level 1 organizations. If you honestly assess your capabilities, or if you use RAD exclusively, chances are, you'll land at level 1 as well. At level 2, developers consider the process repeatable, but developers and architects keep the experience inside their heads. Level 3 is the nirvana of application development, where the process of client/server application development is well defined and built into the infrastructure of the organization. In level 3 organizations, developers focus on the development effort at the departmental level and distribute information across projects. Level 3 organizations use RAD as well, but they don't let RAD drive the design, nor do they allow developers to do an end run around important activities such as system testing, design reviews, and performance engineering. Very few organizations can claim level 3, and most that do, aren't.
Level 4 of the CMM means that you have a measurement process in place and a mechanism with which to control quality, which in turn provides for better managerial control. Level 5 means that managers are processing the information from the level 4 processes -- and performing process-improvement activities using innovative technology and ideas. Table 1 outlines the five levels of the CMM.
There are tons of examples, some of which I discussed in a previous column (see DBMS, December 1996, page 24). For instance, well-designed applications with only 20 objects now contain over 100, many of which are redundant. These extra objects add to the overhead and make maintenance complex. We have little reuse inside the RAD application, outside the application, or among projects. What's more, when you try to RAD your way through the design and development process, it's easy to make simple errors that nonetheless require large amounts of debugging time to fix.
Reuse is the first victim of RAD. Although object-oriented client/server development tools provide natural mechanisms for reuse, the use of RAD often means that developers won't have time to design their application for reuse. Reuse does not happen by accident; you have to plan for it. In projects that award developers for productivity and speed of deployment, you will not see much code reuse.
The fact is, if you try to RAD your way to success, count on lots of clean-up time on the project's back end. In my experience, developers rarely clean the code, and system maintenance means solving problems by layering on patch after patch. This results in a shorter life cycle and user dissatisfaction.
Second, don't neglect the design or a sound development process or methodology. There is no need to go overboard, but a set of 10 to 20 tasks (including requirements, database design, analysis, object modeling, and testing) is appropriate for most systems. Complex systems require more rigorous plans, and less sophisticated systems need less. Methodologies are available to suggest tasks for your process, or you can customize your own to fit your requirements. The goal is to eliminate trial and error, max out on the number of reusable objects, and provide quality checks for analysis, design, and development activities. This sounds expensive, but you'll save big bucks over time. Because you can reuse most of the application in other applications, you will cut maintenance costs and extend the life of the application.
Finally, use your prototype to supplement the application design, not to replace it. In other words, don't throw the baby out with the bath water. Application and interface prototypes are a great way to gather requirements and get a jump on the application development process. RAD is a great tool. For now, however, proceed with caution.
TABLE 1. The Five Levels of the CMM (Source SEI). | |
| Level | Description |
|---|---|
| 1. Initial | The software process is characterized as ad hoc and occasionally even chaotic. Few processes are defined, and success depends on individual effort and heroics. |
| 2. Repeatable | Basic project management processes are established to track cost, schedule, and functionality. The necessary process discipline is in place to repeat earlier successes on projects with similar applications. |
| 3. Defined | The software process for both management and engineering activities is documented, standardized, and integrated into a standard software process for the organization. All projects use an approved, tailored version of the organization's standard software process for developing and maintaining software. |
| 4. Managed | Detailed measures of the software process and product quality are collected. Both the software process and products are quantitatively understood and controlled. |
| 5. Optimizing | Continuous process improvement is enabled by quantitative feedback from the process and from piloting innovative ideas and technologies. |