Let's look at this from a configuration management perspective. What are the relevant points? We must control:

1. The qualifications of the developer
2. The operating system and computing environment in which development is being executed
3. The software used to write the code
4. The code (files) being written
5. The style or methodology by which the code is written
6. The code being referenced

All of these points go to the development environment being suitable, reliable, reproducible, documented, and meeting the requirements for intended use. Let's address each of these specifically.

You must have developer qualifications on file. These should include degrees, certifications, training and relevant work history.

You must define the operating system and intended computing environment in which development occurs. This depends on the type of software being written, so let's say you're developing forms and reports for Applied Biosystems SQL*LIMS version 4.1. You need to define the version of the Windows operating system, the Oracle RDBMS, the operating system of the SQL*LIMS application tier and any other environmental elements relevant to the deliverables that will be created. Additional elements may be installed language support, fonts and required supporting software (Microsoft Word, Excel, Project, etc).

You must define the software used to write the code. For SQL*LIMS forms and reports this will be Oracle Forms and Reports and some developer tool used to write PL/SQL code such as PL/SQL Developer. Do not forget to document the specific patches required for the Oracle Forms and Reports tools, since SQL*LIMS is delivered with specific patch levels applied to the base product.

You must have a method of storing working copies of custom code, and providing file backup solutions so that valuable work cannot be lost due to hardware or software failure. For developers working in a corporate environment, you can look to your corporate IT department for solutions. For developers working at home look into an alternate backup solution. If your department will allow it, certain Internet backup solutions like the Connected Corporation offer excellent services for very little cost. For storing versions of working copies of custom code, look to your corporate IT department for solutions already used for source code control like Rational ClearCase, or Microsoft Visual SourceSafe. For developers that are working from home look into CVS or Subversion. It should be noted that storing versions of pre-released code will help your department track down future software bugs, and should be stored in a manner that is compatible with the source code control program used once the final product goes into production.

You must define coding standards before coding begins. Obviously, look to your department and similar departments in your organization first. If you do not have access to existing standards, talk to your developers; good developers will have coding standards (even if undocumented) already in place. If you have neither of these resources, look to the pros: Steven Feuerstein is the authority on writing PL/SQL; Sun is the expert on writing java, etc.

Finally, you must provide to your developers all the code to be referenced. For writing SQL*LIMS applications, your developers will require the SQL*LIMS source CD (purchased from Applied Biosystems), and all the SQL*LIMS 4.1 patches to date (available to SQL*LIMS customers on the SQL*LIMS Software Support website). Also, your developers will need a copy of the "empty form", which is a template form that already contains all of the basic SQL*LIMS functionality – access to attributes, attachments, application options, etc. The empty form is not on the source CD, so you'll have to call Support directly and whisper sweet nothings. If you still can't get the empty form, have an experienced SQL*LIMS developer create one from a form on the source CD. I recommend opening Results by Sample and removing the result and sample blocks for starters.

In the fashion of last week, here's a short questionnaire to help you determine how well your development environment 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 have all developer qualifications on file and updated within the last year?
2. Have you documented the required computing environment in which development will take place?
3. Have you documented the names and versions of all software used to write the code?
4. Do you have a method of source code control and software backup?
5. Have you published coding standards for all languages/programming environments?
6. Have you collected and published all reference code?

I'm feeling lenient today: if you answered yes to at least four questions then contact me and introduce yourself, I'd love to hear the specifics of your success. If you answered yes to fewer than three then your department is in sad shape and I raise serious concern about the integrity of the software that will be delivered.

Next week: Developers and Validation Professionals: Communication