Programming for the Future--Surviving Upgrades

28 Feb, 2002 By: Bill Kramer

Will our custom programs run okay after we upgrade AutoCAD? What types of difficulties or hurdles will be encountered? I often hear these questions when new releases of AutoCAD become available. Unfortunately there is no simple answer. However, I do find that when pressed for an immediate answer, it's best to say there will be some issues to resolve in the course of the update and the specifics have yet to be revealed.

The answers are not difficult if you know the software in question and how it was written. But the route to the answers involves more questions. For starters, whether a custom program or suite of programs will operate after an upgrade will greatly depend on the tools used for customization, and the programmers who were involved and will be involved. This month I'll present an overview of the issues you might encounter when upgrading custom applications. I will also explore some answers to difficulties that you may run up against and present some concepts for future programming. This is a broad subject and each situation will be unique. My goal is merely to start you thinking about these things before the next upgrade cycle.

The Tools
First, explore which tools were used to create the application. AutoCAD supports a large variety of customization tools such as blocks, menus, scripts, and programming languages of various complexities. There have been upgrades in the past when various items did not move up too well. An example would be a complex screen menu (the one normally not used any more) being migrated to a pulldown menu structure. In many cases this requires redesigning the custom system to make it more suitable for the current interface styles of AutoCAD. The good news is that customization tools such as the screen menu are slow to fade from the scene. Interface options such as the screen menu and command-line prompt are considered archaic by today's standards; however, they are still available.

In looking at the basic customization tools provided in AutoCAD-Menus, Blocks, Visual LISP (formerly known as AutoLISP), VBA, ActiveX, and ObjectARX--guessing the difficulties each will experience during a migration is not difficult.

You can expect that the older tools such as menus, blocks, and Visual LISP will suffer the least during an update while new tools such as VBA and ActiveX will be expanded. ObjectARX, on the other hand, has been subject to radical changes based on the operating system and development tools used. A related tool called ADS was first made available in AutoCAD Release 10 (for IBM OS/2) and much of it still survives in one form or another in the ObjectARX system. In recent AutoCAD releases, the ObjectARX interface is stable.

This is not to say that you can simply move the application to the newer platform and expect it to behave perfectly. For example, it is unlikely that you will have to open each block and save it in a newer format for an AutoCAD upgrade if a block library is part of the customization. On the other hand, you will most likely have to rebuild an ObjectARX or Visual LISP compiled VLX file for an update.

Compiled ARX and VLX program modules for AutoCAD 2000 will also run when using AutoCAD 2000i and AutoCAD 2002. Can we expect this trend to continue? I don't know, but it certainly has simplified the upgrade issues for those platforms. In fact, VBA has enjoyed the same respite in that new things have been added, but existing programs seem to work just fine with minimal or no changes.

Generally it is not wise to skip too many upgrades when custom interfaces are involved. The effort one would face to upgrade an application written for AutoCAD Release 12 using ADS to AutoCAD 2002 can result in a redesign of the entire system. While something written for AutoCAD Release 14 might already take advantage of many of the "newer" features and require substantially less work.

Source Code
The next set of questions involves the developers who created the application. Was a third-party solution integrated or a consultant used? Were any encrypted or compiled components used that you do not have the source code for? Are you doing the upgrade work yourself, hiring a consultant, or shopping for new third-party solutions?

It does not matter what programming tools were used. If you do not have access to the source code and the module does not run in the newer version of AutoCAD, it is useless. All too often people send me compiled or encrypted programs from developers no longer in business asking if they can be made to work in a newer release of AutoCAD. In some cases the programmers have made use of features found in the third-party application only to find that the developer has left no avenue for them to continue forward with future updates of AutoCAD.

This is not to say that you should avoid third-party solutions. Instead you should be wise when making use of them. You should find out how long the developer has been in business and how long they intend to stay in business. This can be very important when working with vertical solutions where the volume of sales is low and the developers tend to be small groups or individuals. If they plan to stay in the business and have been around for a number of years and offer consulting services in addition to their software, then you can expect them to be there for the next upgrade. But it is a good idea to check each time in case the situation is changing.

Libraries of encrypted software from the Internet and books are something to be wary of. In those cases it is always best to start with the source code so that you can update it as part of a migration effort. It can be tempting. There are some tasty morsels out in the market and many that would seriously improve your application development efforts in the short term. But that is the key concept here, the short term. The future upgrade might be a nightmare as you find that you can no longer provide the same type of integration or features as that utility has fallen behind and not been updated. Of course, you can hope that everyone uses the utility and that the developer becomes strong enough to last for years or that Autodesk buys it up and adds it to the basic package. You can always hope, but my experience is that a lot of good ideas like that often are passed by for other even better ideas as the future unveils itself.

When using consultants always insist on getting the source code. Sometimes consultants will be reluctant to hand over their "secret" libraries or perhaps they have used some source code under contract with another developer. In those cases, insist on a copy of the source code to be placed in holding should they not be available for future upgrades. Except for very rare cases, the consultant should have no problem with such an arrangement using a bank safety deposit box or entrusting it to another entity provided you pay the expenses, which leads into the next consideration.

Budgeting for Migration
When creating a custom solution, a lot of people forget to budget for the future. All too often we seem naive to the fact that software costs money and takes time to create. And once created, it will require revisions and updates as the technology improves and users discover new features.

You can expect the migration of a custom solution to cost at least a significant fraction of the original development. Since the design aspects of the application can be considered mostly complete, most of the processes should migrate without any significant changes if the application was well written using a modular apporach. What that fraction is depends on the factors we've already explored plus how much time you can devote to testing for potential problems.

If you spent a month building a custom menu with lots of blocks, you should expect to spend at least a day or two making sure everything works okay, and then you will also need to install it where needed. For smaller groups the installation time should be nominal. Larger installation groups will obviously need more time unless some form of automation is employed for the update or a central server is employed to dispense the upgrades in an orderly fashion.

Testing the upgrade is an important aspect of the migration and may often require the most time. In fact, testing never really ends when you think about it. In a complex application, it is almost impossible to test for every permutation and possible input unless an infinite number of testers are used. So the best thing is to test it as well as possible within a reasonable time constraint and release it to the user community for further testing under fire. In scheduling a migration of a custom solution, allocate some time for sudden interruptions caused by the result of this user testing. Ideally it will be minimal, and the time can be spent nervously awaiting the call to a disaster (however, most experienced IT managers will be quick to tell you that this is rarely the case).

Prepare for Migration
The preparation for migration of an application to an upgrade begins when you first design and write the application--or at least it should. Software and platforms evolve--that much is a given in this rapidly changing world of computers. In addition you will come up with newer and better ideas that take advantage of emerging technology. Thus planning for change and expansion in the initial programming is a good idea. This sounds like an easy concept, but how does one actually do it? The following tips will give you some starting points.

Always play by the rules. When writing an application it is always tempting to take advantage of some undocumented feature or some quirk you learn about in an online discussion group. This practice should be avoided unless there is no other way to accomplish your goals. Undocumented features can be considered bugs in other people's eyes or they could have resulted from a programmer slipping something into the code and forgetting to remove it. Either way, there is a chance that it will be subsequently taken out in a later release.

Understand the rules of the game. In order to play by the rules you must understand them. In the case of programming AutoCAD applications, there may be memory or some other constraints. A classic example would be an application that opens objects and does not properly release and close them. Although the program works great under simple testing, it will eventually run into trouble.

Document any areas in which you do not play by the rules. There are times when it's required to use features not actually documented in AutoCAD. Examples would be some of the extra utilities provided in an unsupported fashion by Autodesk and others on the Web. You can use these utilities to perform a number of tasks by plugging in some of the holes remaining in newer tools such as VBA. When you take advantage of one of these tools, be sure to mark where in the code you used it and explain how to get it if it becomes lost. This way you can quickly find it again and make changes as it evolves into part of the AutoCAD package.

Use structured programming methods and be consistent. Strangely enough this can play an important part in the way your code migrates, especially if the change is at the operating system level. By remaining consistent and using modular programming you can isolate areas that need changed as specific items are identified. With "Cut and Paste" editors it is easy to clone areas of program code, make a few changes, and then charge forward. While this practice can save some time during the initial coding, it can sometimes be a problem during migration. The best advice is to think about the code section before clipping it. When anything involving the operating system or AutoCAD host system is involved, it is recommended that you use a function or subroutine to accomplish the task and thereby isolate it should any changes be required as the result of a later platform change. Of course, some prudence is suggested. A feature that has been available for many releases will most likely continue to be available.

Avoid compiled libraries by always insisting on source code from consultants. I mentioned this earlier, but it is important enough to say it again. The lack of source code will put an immediate end to any update or upgrade work you have in mind for an application. Your only choice will be to either redesign the entire application or spend the time to build the missing pieces over again.

When using third-party solutions, make sure they will be around for a while and budget for update costs for those modules as well. Third-party developers need to make money too, and you should expect to pay for any updates they provide as part of the ongoing cost of the software evolution. If a third-party developer has been around for a few years, there is a good chance that they have a fair upgrade policy already in place.

If you don't understand how it works, it will cause a future problem for you. This is something I have learned over many years of programming, and other programmers have also run into this. Mystery code and algorithms should be treated as a challenge to be decoded. If you don't understand them completely, they will present a future update problem.

I've Been There
I will close with an example that summarizes these concepts. Once upon a time there was a utility provided as an unsupported feature in MS-DOS. I needed it fast to add a feature, so I pulled it down from the support forum. It was supplied as a COM file in the form of a driver, and I plugged it into the application I was creating. It worked great, but only on MS-DOS, and I needed the utility to run on the Macintosh OS as well. It simply was not available--it was a bonus someone had provided showing how to abuse an undocumented MS-DOS feature.

No source code was available either, but after drawing on every connection I had, I managed to get it. Alas, it was written in Assembler and could not be ported to the Macintosh directly. The story gets very technical from that point on, but the lessons the experience taught were driven home. I will simply say that neither application environment is running anymore. The application was ported to another operating environment altogether after running for several years on both MS-DOS and Macintosh. Software does not last forever.

Until next time, keep on programmin'!

About the Author: Bill Kramer