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.
