Introduction: Software as a commodity

For the next couple of weeks, we are going to be taking excerpts from a book I wrote titled (appropriately enough) The Right Way To Build Software: A Comprehensive Guide to What To Do and What Not To Do.  We are going to start with today's installment Software as a Commodity.  It is both and introduction and a problem statement and in subsequent posts, we will expand on how to solve this particular problem.

Software as a Commodity

If you buy an apple from Safeway you pretty much expect to get the same apple you got last week at Kroger.  Apples aren’t differentiated based on where you buy them or how they got there, they are intrinsically apples.  If you apply that same logic to, say, automobiles, you run into trouble quickly.  If you walk onto the Mercedes lot and attempt to compare one to a Chevy, you may find that you pay twice or even three times as much for something of comparable dimension.  A car is not just intrinsically a car.  If we take the analogy to the next logical step, cars do things that apples don’t do, and we can compare them according to those things: headroom, gas mileage, horsepower, etc.  All the things we use to make a decision pertaining to a car can be quantified and measured.  This data is readily available to the consumer via buyer’s guides, showrooms internet searches and sources ad nauseum. 

The problem we are trying to solve is how to write software effectively.  While this doesn’t’ seem to pertain to apples or cars, the similarities are striking.  Most software developers don’t have and don’t’ want to have anything to do with the business world.  This means that the software buying/writing decision is made by people with little or no concept as to how software works, or even really how it accomplished the things they see in the glossy brochures.  They make decisions as if they were buying apples.  One developer is as good as another developer and if the business doesn’t get what it wants from the first one, there are a hundred, probably cheaper, right behind him or her yelling they he or she is Cinderella and to hand him or her the glass slipper.   This is only part of the problem, though.  Buying or writing software isn’t like buying a car either.  There are few if any established benchmarks for making the buying/developing decision.  A business person can’t kick the tires or even test drive the program like they can a car.  Even worse, since the managers making the decision aren’t software people, they don’t’ even know what to ask the sales team that vends a potential piece of software or what questions to ask a potential developer.  They fall back on tried and true questions used to hire everyone else up to this point.  “Do you have experience with this?”  Can you do that?”  These questions lead to the same software that didn’t work in the business the developer came out of and the same mistakes that caused them to fail there as well. 

So software isn’t a commodity, and with a little thinking we can see this as self evident.  Since we can’t take it on a test drive, or compare mileage between Company A’s application and Company B’s application, what should we do?  Tomorrow, let’s take a look at the current state of affairs as that-which-should-not-be-done and break that down into its constituent pieces so we can reconstruct it in later chapters as that-which-should-be-done.

Go and take a look at our sister blog: http://sentiahealth.blogspot.com.  Today's topic is Health IT Security, a 'How To.'