The Ponzi Software Development Scheme

The metaphor Ponzi Software Development Scheme, came to me after I have been read about a post from CACM, The Death of Big Software. The traditional big softwares will die away, because they are easily growing to become too hard to maintain, and will be replaced by cloud or microservices architecture based softwares.

But will cloud or microservices save big software projects from failure? I rather say, no silver bullets, neither cloud nor microservices. Actually, here the “big” software projects are misleading, software projects fails not because they are big(big repos of code, big set of connected components, big set of requirements/features), software projects fails when they fall into the Ponzi software development scheme. Of course, big software projects are prone to evolve into the Ponzi software development scheme.

To elaborate, I would address the following metaphors first:

• The metaphor of debt: the monetary debt is to borrow money to build or accelerate some business, and repay the money and the interest back later. The technical debt is to use some ad-hoc but fast methods to accelerate the software development process. The methods used may be insufficient, or poorly designed, or barely test covered, or logically inconsistent.
• The metaphor of leverage: the leverage can be considered as the process of taking debt to build big business. In the technique literature, the leverage can be viewed as taking technical debts to rush through some big features or products.
• The metaphor of debt bomb: The ever increasing debt level is like a time bomb. When a debt bomb explodes, there will be finance crisis. When a technical debt bomb explodes, there will a lot of bugs, failures and vulnerabilities.
• The metaphor of deleverage: the process of deleverage is to reduce the debt level, or the leverage level. In the technique literature, the action of deleverage means focusing on refactoring of poorly developed modules instead of building new features.

The Ponzi Scheme is a fraudulent investment operation where old debt is repaid with new debt, the debt level never decreases. Once the debt bomb explodes, the operation will fail. Likely, the Ponzi Software Development Scheme is a fraudulent software development process where the technical debt level keep increase until the technical debt bomb explodes, the software becomes unable to maintain, the software collapses.

There is another similarity for both the Ponzi Scheme in finance and the Ponzi Scheme for software development, any finance or software development operations are prone to fall into the Ponzi stage despite the original intention is either good or not.

Let’s take a look at how software projects step into the Ponzi stage. When we say some features are delivered in a software project, what do we mean about delivered or what exactly are the things delivered? Usually, we describe things delivered with product functions and experiences, or in detail form with test cases and performance specs. People are aware of the new version or features delivered, not only the users and bosses, but also including the developers and managers of the software. But that’s not enough, what we didn’t mentioned in the delivered list, are the technical debts taken during the development process, and technical debts already accumulated are usually ignored too.

So, every time something is delivered, along with product functions and experiences, technical debt is also delivered. And accumulated technical debts becomes elephant in room until they are too big to be deleveraged. Step by step features delivered, step by step the software project grows big, and step by step the software project walks into the Ponzi Scheme.

Why the software projects always step into the Ponzi stage without being perceived? Here comes a key difference between the Ponzi Scheme in finance and the Ponzi Scheme for software development. The monetary debt level can be listed in the balance sheet, especially for public listed companies. But the technical debt level are very hard to measure, they are invisible. The monetary debt is obviously trackable by accounting, but the technical debt hide beneath the surface of software development process. From The Mythical Man-Month, The project estimation is very hard, but I think the technical debt estimation is even harder, the technical debt is not even measurable. Something unmeasurable will not be put into KPI or report for executives, no one actually cares, so big software projects enters the Ponzi stage are inevitable, especially for those big CRM/ERP projects.

The direct resque for solving the Ponzi Software Development Scheme is to perform deleveraging. The deleveraging process is painful yet long term, actually lots of enterprises simply build a whole new version of softwares and get rid of the old version. But any operation adopted, will affect the development of new features due to the limitation of resources. Deleveraging on the old version seems like a long term surgical operation, deleveraging by building new version would require huge cost on both time and money, plus a painful transition procedure. And usually, the new version built will soon fall into the Ponzi Software Scheme again. So the process of deleveraging requires firm support from executives and carrying out by sophisticated people.

Will cloud based services or microservices based architecture help for deleveraging software projects? At least adopting those auxiliaries, can reduce the cost for building better softwares, or cost for deleveraging process. But services are not silver bullets as I mentioned before, while the amount of depended services increases, the complexity of integration and scheduling will grow exponentially. The complexity is essentially bound with the software development process, and ignorance of the complexity would lead to the Ponzi Software Development Scheme. Most of software projects already in the Ponzi stage, are deeply bound to traditional architectures, refactor the projects to services based architecture would also be a very struggling process.

At last, I would say that the Ponzi Software Development Scheme is just another metaphor to state the complexity of software development. There is no silver bullet to solve it with a single shot. But the more people know about it, the less software projects are tend to fail. So, let the people know about the Ponzi Scheme would save their money, and let the coworkers and executives know about the Ponzi Software Development Scheme would save them from failure and collapsed softwares. Bring the the complexity of building softwares into the common sense, helps to build softwares to last.