[an error occurred while processing this directive] [an error occurred while processing this directive]
Jeff Vannest's Weblog

Main | "Controlling the Development Environment" »

February 04, 2005

Controlling Code

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 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 need to consider taking a job in another industry – I suggest an Internet startup of some kind.

Next week: Controlling the Development Environment

Posted by Jeff Vannest at February 4, 2005 08:55 AM

Trackback Pings

TrackBack URL for this entry:
http://www.jandrconsult.com/cgi-bin/mt/mt-tb.cgi/3

Comments

They that approve a private opinion, call it opinion; but they that mislike it, heresy: and yet heresy signifies no more than private opinion. by texas holdem

Posted by: online poker at February 22, 2005 06:26 AM

Well, I was all excited that I had a comment. Serves me right that it was for an online gaming website. Hrumph!

Posted by: Jeff Vannest [TypeKey Profile Page] at February 22, 2005 08:52 PM

Post a comment

Thanks for signing in, . Now you can comment. (sign out)

(If you haven't left a comment here before, you may need to be approved by the site owner before your comment will appear. Until then, it won't appear on the entry. Thanks for waiting.)


Remember me?


 
[an error occurred while processing this directive]