How much time do your developers spend writing small routines or tools that may be used only once or twice? Of course, a finish tool or routine may be placed into a "tools" library where other developers have access to it, but why do they spend time writing these kinds of things when there are still huge application backlogs pending at virtually all AS/400 and iSeries installations?
Often, a staff programmer or onsite consultant will decide to create a tool (the quality of which we'll leave for another time) that they think will be useful. Should you let them?
The answer is "yes" and "no." You should allow your staff or full-time consultant to "play in the sandbox" as they say. They should be allowed to experiment with some of the system functions for no other reason than the experience. Hopefully, it will be a learning experience.
Often, the topic of my Midrange Developer articles is essentially a sandbox-style creation. I read, plan, experiment, observer the results, and repeat the process. This has led to hundreds, if not thousands, of tools and utilities that I've authored and published over the years. Years before there was a QUSRTOOL library, I was shipping my Q38LIB, COZUTIL, and UTIL400 libraries.
I don't expect most shops to produce the kind of tools that are commercially available, but there are shops out there whose in-house staff has created some very useful stuff. If you set boundaries, time limits, scope, etc., your staff can actually help educate themselves by playing in the sandbox.
Of course, not everyone on staff will have the skill set or the ability to be productive at this, and there is always that one person who likes to throw sand. But perhaps there are one or two who may benefit from playing in the sand box.
Try to rotate most of the staff though a planned sandbox outing. Give them some parameters and a time limit, discuss the kind of tool or utility they are going to attempt to create (perhaps one that's been sorely needed by your shop), and then give them the freedom to experiment. Once their time is up, consider having the rest of the shop beta test the tool and then do an in-person code review and documentation evaluation. If the tool doesn't get finished, they can continue on it next time, have someone else complete it, or even work on it in their free time, after hours. Either way, your company benefits from the knowledge they've gained building the tool.
The goals of playing in the sandbox should not necessarily be to create the next great OS/400 utility software that you might sell. Believe me, only a handful of companies have made money doing this in the OS/400 marketplace. Your goal should be to encourage ongoing learning about the operating system, give your programmers' minds some diversity, and encourage creativity that could spill over into your business applications. If you do, then maybe, just maybe, they might become better, more-productive programmers.
Bob Cozzi has been programming in RPG since 1978. Since then, he has written many articles and several books, including The Modern RPG IV Language--the most widely used RPG reference manual in the world. Bob is also a very popular speaker at industry events such as COMMON and RPG World and is the author of his own Web site, www.rpgiv.com, and of the RPG ToolKit, an add-on library for RPG IV programmers. Bob runs his own one-man iSeries consulting and contract programming firm in the Chicago area.
LATEST COMMENTS
MC Press Online