|
[ Go to August 1997 Table of Contents ]
Control Your Coders Letting a nonprogrammer modify mission-critical data is a sure way to stress-test your disaster-recovery mechanisms.
It's okay to let your nonprogrammers code. You just have to make sure they know their limitations-and their limits. Last month I talked about the people issues that arise when amateur programmers in your shop start writing production code. This month I'll address some of the equally tricky technical considerations. Changing data is forbidden. Don't let a nonprogrammer's creation modify mission-critical or even mission-valuable data. Reading such data and producing a summary is fine and might be all that's needed to eliminate a bottleneck, but letting a nonprogrammer change such information is a sure way to stress-test your disaster-recovery mechanisms. A hammer often makes an acceptable screwdriver. Almost none of the usual technical aspects of tool selection apply to this situation. Choosing development tools normally requires subtle trade-offs between speed of development and the performance and maintainability of the finished program. When a nonprogrammer is willing to bail you out, you have to go with whatever tool set your hero already knows and is willing to use, except in extreme cases. System friendliness counts. Your amateur programmer will likely want to use a rapid application development (RAD) product, such as Borland's Delphi or Microsoft's Visual Basic. If so, make sure you know what's needed to install the finished program onto multiple systems. Visual Basic 5.0 applications, for instance, require you to install 2MB of support files on every system. This doesn't pose a disk-space problem, but it does represent 2MB of configuration changes, for even the most minor of programs. That should put your paranoia setting on red alert. Similarly, don't let your programmer change the user's WIN.INI or SYSTEM.INI files or Windows 95 Registry. (You can allow a Registry change for creating a file association that links a document type to the new program, but if at all possible, draw a line in the silicon there.) The program should store all its configuration settings in its own INI file to minimize the impact to the system configuration and make uninstalling the program far easier. Thin is still in. Once people use the new program, you'll get a flurry of requests for enhancements. Hold all such requests to the same standards as the original project: If the change is necessary and is a relatively minor risk, then go for it. But make sure you keep a copy of the program's previous version (including source code!), in case the new one is a disaster. Keep the user interface of the program as streamlined as possible. If your programmer starts talking about multiple wizards, it's a sure sign this isn't the right project to tackle, or you've got the wrong person doing the tackling. May the source be with you. Even though you should assume the program will be disposable, make sure you archive the source code. You may need to make a very small change or bug-fix to the program six months (or a year) down the road, after your programmer has moved on. Also, make sure you have a copy of the development tool used to build the program, including all libraries. RAD users love third-party component packages, because they can greatly shorten the development cycle. You need the add-on packages to rebuild the program, and if you don't have them, you may hit a compatibility problem if you substitute the latest versions and find the program no longer compiles or runs properly. Don't provide too much help. Advise your programmer not to write an extensive Windows help file unless it's truly needed. A minimal one should do, or even just a dialog box in the program that displays a set of hints and tips. With a little care and attention to these issues, you can let your people spread their wings, and it will be a productive and fulfilling experience for everyone involved. Contributing editor Lou Grinzo is president of Lou Grinzo Technologies, a computer consulting and contract programming firm, and author of Zen of Windows 95 Programming (Coriolis Group, 1995). Contact Lou care of the editor at the e-mail addresses here.
|
