Confidence Games in Software Engineering

Have you heard the pitch for the tool that gives a 600% productivity improvement, or the new programming language that will solve all of your problems? Matt Heusser explains that confidence games abound in software development - and suggests what to do about them.

Like this article? We recommend

Like this article? We recommend

You probably know that the foreign drugs offered in your email inbox are not
legal or FDA regulated, but you may not know that many of those drugs are
entirely fake. Ten cents a dose for prescription medicine is not a good
deal if the vendor ships sugar pills—or poison.

Those sugar pills are a confidence scheme—they offer to provide
something that ultimately isn’t able to live up to its promises. The term
brings to mind images of back-alley deals with shady characters, but confidence
games occur everywhere in this world. Finding con artists can be as easy as
turning on your television: Cars and alcohol promise joy but provide only
passing entertainment. Real estate infomercials promise riches but deliver false
hope. Dial-A-Date and other, less reputable services promise intimacy and
instead provide just a fleeting illusion.

Yet we have a need for the things that these frauds promise; that’s why
they’re so appealing. We also have pains and needs in the world of
software development, with some real solutions...and some more dubious ones. The
software vendor who promises that his three-letter-acronym will solve all of
your problems, the consultant who promises a 300% increase in productivity with
his patented system, and the certification vendor offering a 50% raise and
guaranteed career are all promising more than they can deliver. Let’s
consider a few of these con games, along with the corresponding real
goal, why that goal is so difficult to reach, and alternative steps to get
there.

Three-Letter Acronyms

Does anyone remember ERP? Enterprise resource planning was supposed
to solve the problems inherent in a big company where different departments (and
business units) weren’t talking to each other. According to Barbara
McNurlin and Ralph Sprague, [1] ERP is "tightly integrating the various
functions of an enterprise so that management can see cross-enterprise financial
figures and order and manufacturing volumes."

One western Michigan company went through a large ERP conversion to solve all
these problems—but they wanted to keep the existing, best-of-breed HR
system along with the ERP system, the data warehouse, and several other in-house
applications. While the ERP system helped, keeping these systems synchronized
caused the same kind of integration pain that ERP was supposed to fix. After
introducing the subject of ERP as the next step forward for the information
services group, McNurlin and Sprague conclude that ERP implementations "are
huge, expensive, and many failed."

The next touted idea was enterprise application integration (EAI),
which was supposed to solve the problems of ERP by enabling loosely coupled,
distributed systems to talk to each other by trading messages in XML, often
through a server. The problem was that when the server (hub) went down, so
did the entire business.

Enter service-oriented-architecture (SOA) and the enterprise
service bus (ESB), which create a "redundant server you can
trust"; the problem is that nobody knows what that expression really
means. One publisher went so far as to suggested a roadmap for
companies to follow in order to develop a strategy that will,
hopefully, produce an architecture. If a roadmap to a strategy to a high-level
architecture sounds a bit too fluffy, a number of vendors and consultants would
be happy to help you implement an ESB that hooks into a SOA that enables EAI
back to the original ERP system. The full-page ads were in the periodical, right
next to the article on SOA. How...helpful.

Have you noticed a pattern here? The vendor or consultant promises to solve a
problem, partially solves it, and then keeps the company on the hook for the
next "solution." The real goal of consulting companies and vendors,
after all, is to make money. It may be unintentional, but it certainly fits the
definition of a con game.

Now, I’m not opposed to the idea of SOA; in fact, many large
organizations that need to pass huge amounts of small bits of data on demand
(airlines, companies with legacy/mainframe systems, massive retailers), or
companies integrating due to mergers and acquisitions, could find great benefit
in the SOA approach.

The rest of us may be better off simply avoiding the problems that SOA
supposedly solves—redundant systems, systems that don’t talk to each
other, and bad integration. Avoiding those problems requires good architecture,
managed growth, and team discipline. For example, if the real goal is
good integration, that might require strong execution of systems
integration—instead of cleaning up the mess with middleware afterward.
Leadership and initiative can help accomplish the real goal of data integrity
and consistency far better than any alphabet soup.

Leadership, integrity, initiative, and vision cannot be outsourced or
purchased from a vendor. They won’t increase the size of an empire or
create new, marketable three-letter abbreviations for a résumé.
Focusing on good work will often detract from focusing on image and appearance.
Still, when good work conflicts with image, good work should win. We’ll
come back to this issue later; for now, let’s talk about process
certification.