|
[ Go to July 1997 Table of Contents ]
Let My People Code You should seriously consider using programs created by nonprogrammers when your back is up against the wall.
Your backlog IS eyebrow-deep and getting deeper, and you're frantically searching for a better way to use your fleet of Windows PCs, when one of your people walks into your office and says, "You know, I program on my home system, so I could write some little utilities to speed things up around here." The problem is your eager volunteer isn't a programmer, either by training or profession. What do you do? The simple, overly cautious reaction is to reply with a firm but polite "No" and try to muddle through. But that's a mistake, largely because of the curious nature of computer programming. Even among professionals, programmers are often self-taught. They do it because they love it. So don't immediately discount the idea of using programs created by nonprogrammers. Think of it as exploiting an available resource to solve a problem, empowering people or both, and consider it if your back is up against the wall. Here are some pointers to help you avoid problems on the people side of the issue: Don't ask. If people volunteer to write minor programs here and there, let them (subject to the guidelines below and in next month's column). But if they don't volunteer, don't push them. A direct request to create something might encourage a person to exceed his or her limits, with dire consequences. Limit solicitations to a blanket invitation to the entire workgroup unless you're truly desperate. Set limits. Make it clear that having Sue in tech support write a small application is not a blanket endorsement for employees to write and use their own programs or bring other unapproved software to work. Your users must view any new in-house development as an exception to your existing software policy, not a replacement for it. Also make it clear that there's no downside to failure; if someone creates a useful application, you should recognize that person for making an exceptional contribution. But if the application fails, there's no stigma attached. Although it's important to set limits, don't even think about trying to prevent minor acts of programming, such as the creation of application macros. Your more experienced Windows users are very likely writing and passing those around already, and nothing you say will stop them. You also have to limit the size and complexity of the project. Your volunteer will probably be very enthusiastic about getting a chance to write production code and therefore likely to get carried away with the scope of the program. You're not looking for fancy multimedia effects; you need the simplest possible meat-and-potatoes program that does the job, and you need it now. Let requests from users determine what gets added in version 2.0 or even whether there'll be a version 2.0. Be selective. Approve only those projects that will provide a significant benefit to the organization, and shun those that would simply be nice to have. Maybe your group really can benefit from dozens of new applications, but you should attack only those problems that promise a big payback. After all, there's no point in taking the risk of having nonprogrammers write production code unless the potential benefit is significant. Anticipate failure. Topflight commercial software is (or should be) laced with mundane things programmers don't like to do, such as checking for errors from calls to Windows functions or other parts of the program, or detecting and working around "pathological cases" that "shouldn't happen." Rookie coders are much less likely to handle such issues gracefully or even to know enough to look for some of them. As a result, it's possible an amateur will produce a program that will run perfectly 95 percent of the time, and crash and burn the other 5 for no discernible reason. Next month, I'll discuss the even more treacherous technical issues. 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 at WINDOWS Magazine's areas on America Online and CompuServe, or at the e-mail addresses here.
|
