Confidence Games in Software Engineering

• By Matthew Heusser
• Mar 17, 2006

Like this article? We recommend
Software Testing, 2nd Edition

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.