CASE tools are not the answer to every data processing shop's programming backlog. Many of the CASE tools on the market advertise that their products not only reduce the programming backlog, but that they solve many common problems associated with programming. I have found that CASE tools do indeed solve many problems. However, I feel that the increase in efficiency is often overstated, and the tools introduce a whole new generation of problems.

Marketing representatives from many of the CASE tool vendors tell of how their tool can single-handedly solve your shop's backlogs. One problem with the CASE tools is that most of them have a steep learning curve to overcome...sometimes as much as six months or longer. Consequently, if a shop is behind schedule before it purchases a CASE tool, one has to wonder where will it be six months after the purchase.

I am not disputing that once a programmer gets familiar with a CASE tool it can become a valuable asset. However, the increase in performance is often exaggerated by marketing hype. Using a CASE tool does not necessarily increase productivity on every programming project, especially the more complex ones. The tools available today are effective because they use repository programming techniques and make use of the concept of reusable code. If you need a data entry program, a shell is generated, and then you modify it to do any special programming. Vendor demonstrations of how quickly a program can be generated are quite impressive. However, vendors assume that you would otherwise write the program from scratch. Just as CASE tools use repository programming, so do programmers. I cannot remember the last time I wrote a program from scratch. Programmers do not like to reinvent the wheel, rather they pull sections from existing programs that perform similar routines.

As I stated earlier, CASE tools open up a whole new generation of problems. One such problem is that CASE tools are not able to keep pace with changing technology. Within the last year and a half, IBM has enhanced RPG/400. Even if the CASE vendor is working closely with IBM, language en-hancements may not be available at the same time. Code which is generated by a CASE tool is only a subset of the language; it does not take full advantage of every feature available within the language. As a result, a shop that thinks it is using state-of-the-art technology by utilizing a CASE tool may, in effect, be a step behind current programming techniques.

A second problem is that CASE tools often compromise efficiency and flexibility. CASE tools will not do everything your RPG and COBOL programs will do. Pro-grammers may have to find alternate methods of accomplishing a task, often at the expense of efficiency. These alternatives can end up taking much longer than it would have taken to use a conventional programming language.

And finally, CASE tool literature often promises that using the product makes software much easier to maintain! Perhaps, but if a shop has applications written in conventional programming languages that coexist with applications written with a CASE tool, then experts are still needed for both. In addition, if everything cannot be done efficiently within the CASE tool, experts are still needed for both. This requires special consideration for training and recruitment of programming staff.

I am not suggesting that shops use only conventional programming languages. I am merely stating that you should not expect a CASE tool to solve all your problems. If you share my perspective, then you will not be disappointed by unfulfilled expectations.