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.
Gloria Metrick
GeoMetrick Enterprises
http://www.GeoMetrick.com/
Certainly i agree with you Gloria. Infact i was debating within myself for about 2 weeks why lw lims or any other lims is called as cots when consultants or programers actually put their hands into various functionalities. Even though its called as enhancements we are still trying to change the nature or behaviour of that particular functionality orginally shipped.
Hence i felt it should be treated as any other software application and should follow the normal SDLCycle.
Few weeks back i was debating within myself about the difference between cots and other software applications. When we are enhancing a cots product then it has to be treated as any other software application and should go through the SDLCycle.
The explanation for this is we are actually changing the behaviour or functionality of the cots that was originally shipped so i definetly agree with you Gloria.
Thanks,
Sarath