Controlling Code: Controlling custom code in a validated environment
Picture1″ height=70 alt=”LIMSfinder > Picture1″ hspace=0 src=”http://w3markets.smugmug.com/photos/27112514-M.jpg” width=310 align=middle border=0>
Controlling Code
Jeff Vannest, Senior Consultant
Controlling custom code in a validated environment is a tricky endeavor. Between technical developers and managers and difficult software, it’s often easier to overlook the problem than deal with it directly.
First, if you’re like most projects you have developers that are, well, developers! I can say this because I also develop code and I know how developers like to think. The belief is that code is the important stuff. Everything else, test scripts, project metrics, training records, etc, are just the annoyances that go along with writing code; like having to obey the speed limit when you’re driving a convertible on a sunny day.
Second, IT managers are usually unfamiliar with the validated environment. This means they are comfortable in the IT environment, and generally resistant to running their department like a laboratory. I mean system analysts don’t have to wear goggles and lab coats, right? So why bother with all that lab stuff like writing SOPs and dating and initialing important paperwork?
Third, and finally, it’s hard to find, install, learn and maintain a good source code control tool. You wouldn’t believe how often LIMS IT departments simply put custom code on a shared drive and call it controlled. Granted, it’s not available to hackers (nod to Cisco and corporate firewalls), and it keeps it out of the hands of Sally in Accounting (nod to Microsoft’s Active Directory), but controlled? Not in my estimation.
So, here’s a short questionnaire to help you determine how well your code is controlled. Answer honestly. If you want a true assessment of your department, hand out these questions to your developers and have them respond anonymously. Remind yourself that managers are notoriously informed about what their department is supposed to do.
Acceptable answers are “Yes (completely and always)”, and “No (not completely or not always)”.
1. Do you own a code control tool (not a process, an actual software tool used to control code)?
2. Is the tool used during the development of custom code (before initial system acceptance)?
3. Is code released from the tool for each phase of testing?
4. Is the code re-released from the tool for further customization (after initial system acceptance)?
5. Do you have some method of verifying that a piece of code is precisely the version you think it is?
If you answered yes to all five then you win a prize: find the nearest ATM and take out $100 for yourself. If you answered yes to three or four, then you’re heading in the right direction, but draw up a plan to bring your department into full control of your code very soon. If you answered yes to two or fewer of these questions then you seriously need to reconsider the future quality of your delivered systems.
About the author: Jeff Vannest is a Senior Consultant at J&R Consulting, Inc, a consulting firm specializing in LIMS systems, and excels in technical design, development and implementation. Weekly articles on LIMS software and contact information can be found at http://www.jandrconsult.com .
