First, let me clarify the terms: By "methodology", I mean the philosophy by which a person or group completes a task. In most serious LIMS environments (and we are all quite serious, aren’t we?), methodologies are precisely stated in department procedures and plans. For example, in the testing environments we have a plan and a procedure. A plan is a statement or document describing the items or systems to be tested, and a procedure is a structured set of steps to complete the testing. By "tool", I mean some piece of software used to complete a task. For example, I write PL/SQL using PL/SQL Developer, and JBuilder to write java. These tools are the daily mechanism by which I complete tasks for customers.

Second, let me clarify the question: should a specific software tool be allowed to affect methodology? For example, if my methodology states that X widgets are delivered with Y properties and my software tool doesn’t support the storage of Y properties, should I change the methodology or use a different tool?

Let me give a real life example of the potential problem: I act as webmaster or technical advisor to four websites. Recently, I switched the webmaster of a site over from using Microsoft FrontPage 2002 to Macromedia Dreamweaver MX 2004. As an aside, FrontPage is a good program, but it’s for somewhat novice users. Further, it requires some components that are not industry standard, but so widely used that most web servers support them. Dreamweaver, on the other hand, is a robust design environment built for more experienced users and for supporting current W3C standards. Back to my story: I thought all was well until the webmaster made a change to the page header - the file that contained all of the site navigation, among other things. Since that header file was using a FrontPage include to be inserted into all of the other pages, what would have normally been a change to a single page no longer works. The only way to change all pages in Dreamweaver is to change all 50 of them manually or change the filenames and convert them all over to using industry standard server-side includes. When it came up the webmaster asked me, "Why can’t Dreamweaver do something so simple? I used to do this all the time with FrontPage without all the hassle." What to do? In one of my more obtuse moments I simply replied, "Uhhh....because."

From this example, the lesson is clear: If I had chosen (or even considered) a methodology before designing the website I may have still used FrontPage, but I would not have used FrontPage’s product specific components - components that locked me into using a specific product.

However, let me give a second example. Several months ago I was reviewing the methods by which one gathers project requirements. This is a topic that I, personally, have not been involved in too often, so I had a deep curiosity in the subject. After reading some methodologies (I highly recommend "Writing Effective Use Cases", by Alistair Cockburn), I wanted to review some of the available software tools. One of them was Rational's RequisitePro software. This program rocks! The "Traditional" sample project has a Product Requirements package (a URS) and a Software Requirements package (an SDS). Each package is full of requirements that get linked together. Individual requirements can have a plethora of attributes, can have discussions on the requirement topic, get tracked for traceability between packages, etc. You have views of what requirements have been met, which are not, etc. You can mark requirements for time estimates, stability, complexity, assignment, priority, traceability, as well as many others. Each requirement has a complete history of who changed it, when and why, and how it's related hierarchically to other requirements. But there are two very cool things beyond that: First, everything is automatically placed into a Word document for delivery to the customer, and updates are bi-directional. If you make a requirement change in the document it gets updated automatically in the project. Further, the document is stored in a database (Access, Oracle, DB2, etc.), so it can be versioned, tracked, etc. Second, if installed on an Oracle database, there's a web interface that allows any user connected to the Internet to use it! From what I could gather, the only thing that can't be done on the web is to create the project, but apparently, once the project has been defined, anyone can modify it over the Internet. This is one amazing program. And, more importantly, I learned a lot about gathering requirements through this exercise.

This is the example that typifies my gut reaction. I believe that sometimes tools can drive the methodology, and this is especially true when dealing with areas of emerging competence. The book, "The 7 Habits of Highly Effective People" by Steven Covey is a good example of this thinking: successful actions are guided by unchanging principles. My belief is that if a tool is developed by a competent, reliable source, then the tool will naturally follow the example of good methodologies, and this is an example upon which you can base your own methodology. Remember my tool PL/SQL Developer for developing PL/SQL code? The newest version of this tool supports the inclusion of code comments that can be automatically generated into design documentation in HTML format similar to the javadoc utility for programs written in java. Hmmmm....code documentation written inline with the code...sounds like good methodology to me; I’ll have to talk to Mr. Boss man to see if this is something we should be doing!

So I guess the jury’s still out on this question. Maybe someday I’ll sit down and develop the guidelines by which this problem can be quantified. But for the present, I have a website to redesign.