COTS – Should it Be Treated Like Custom Development?

The other day, I made a posting about custom software development. With the continuation of high project failures in the laboratory informatics industry, one might wonder if one of the factors is lack of control over our projects. Thus, some might ask this question: Should COTS (Commercial Off-The-Shelf) projects be treated like custom software development projects?

Let me start with this: for years, our industry has argued that, since a system is a LIMS/SDMS/ELN that it’s not software. Well, actually, it IS software. It’s not a moose or a pancake or an automobile, and I’m 100% certain of that.

Then, we argue that, since it’s a COTS and we’re just “configuring” it, that it’s a “black box” and we don’t need documentation. I’d say that’s partly true but highly misleading. So, I should explain about the “black box.” In software development, if you are using something that you can’t “see into” and that you are assured works a certain way, you are working with a “black box.” Thus, when you buy software and just use it, you aren’t able to look at the programming behind it. And, if it’s been properly tested, you shouldn’t NEED to look at the code behind it.

I would argue that purchased software really is a black box. When we buy it, regardless what it is, we shouldn’t have to worry about the programming behind it when we are trying to implement it into the laboratory. That’s just good old software development, nothing special because it’s a COTS system.

But I would argue that, once you start to write program code for the system to add on to it or modify its usage, that that does not fall in the “black box” category. Additionally, call it “configuration” or “scripting” or “tuna fish sandwich” but it’s still programming. When you write 1000 lines of code to add a feature to your COTS system, it requires documentation and testing just as any other 1000 lines of code would. And, in fact, I’d say that maybe it’s even a bit harder to test in the COTS system because there are so many buttons and features that could be activated elsewhere in the system to affect it.

Year-after-year, we hear about failed projects. And each year, someone brags about some new tool or product that will solve these problems, or they beat their chest about how much their own projects are better than everyone else’s. Yet, usually with no real proof – just a bunch of marketing spin. And, the following year, we continue to hear about the same failed projects.

In the years I’ve been in this business, I’ve continued to see the same problems. As a single voice in the industry, I can’t change the world, but I’ll continue to work for my own customers as well as to try to promote better practices. Industry leaders rebuff me on this, and there are days when I wonder if I can make a difference in the wider world, but if I can help even a single customer besides those I world with, directly, then I’ve made a difference – helped saved someone some money that they can use toward more features instead of wasting it on project failure.

Currently, there’s a related discussion going on in the LinkedIn LIMS/Laboratory Informatics group. If you’re interested in this topic, here’s the link to it: http://www.linkedin.com/groupItem?view=&gid=36640&type=member&item=24249598&qid=308670b6-6d55-48de-af1b-ef666afe29d7&goback=%2Egmp_36640

Gloria Metrick
GeoMetrick Enterprises
http://www.GeoMetrick.com/