- Don't "Enron" Your Software Project
- Technical Debt: A Primer
- The Enron Model of Technical Finance
- Technical Fraud
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
The Enron Model of Technical Finance
Let's spend a few seconds looking at a little history. One of the big things that got Enron in trouble was that it routinely took risky bets. Depending on the outcome, Enron would count the wins on the main balance sheet, and count the losses in something it called an "off balance-sheet entity"—which basically was a structure, hidden from view, that held the debt related to the losses. Of course, the "off balance-sheet entity" wasn't reported in the financial statements that Wall Street used to judge the finances of the company, resulting in the ensuing scandal.
Sadly, common practice for return on investment (ROI) analysis in software development projects results in the creation of comparable technical "off balance-sheet entities." The occasional ROI analysis will include a line item for cost of ownership; in turn, where this line item has a very optimistic projection for ongoing maintenance costs, rare is the case where such a number is questioned. Rarer still is a case where an organization demands that a Statement of Work require meeting code-quality metrics that help manage down the amount of technical debt with which a solution is loaded on delivery. Put bluntly, most software is delivered with hidden liabilities—"off balance-sheet entities," if you will—that result in today's familiar high maintenance costs.
Costs of the Enron Software Finance Model
It would be bad enough if the costs only involved software maintenance. The damage of this practice is only the tip of the iceberg. The real costs occur when this sense of "custom software is hideously expensive long term" is normalized. Because this is considered normal, companies often do everything they can to avoid writing custom software. As a result, vast opportunities for additional productivity—not just in individual companies, but for the economy as a whole—go unrealized.
I believe that we've already started to see the effects. Time after time, I've seen companies in trouble due to bad software. Companies that could increase their margins by 10% simply by adding a second shift, but they couldn't run such a shift because of limitations in their legacy software—mostly related to maintenance. Companies where technology literally controls how often the company is willing to adjust the commission structure of the sales force. I've seen mergers and acquisitions become unprofitable as a result of high-tech integration costs. (Mergers often force early pay-down of technical debt.) Badly written software, laden with technical debt, extracts a terrible cost on our economy as a whole.