We all despise the tactic. Big companies manage short-term cash flow by deliberately delaying payments to suppliers. The practice, often called accounts payable stretching, or more colloquially kicking the payables can, involves extending the time between receiving goods or services and settling the invoice. It’s a form of questionable financing, where holding onto cash longer allows the business to avoid the expense of formally financed credit. While it may seem strategic during finacial crunches, it soon grows into a necessity. The longer the delay is normalized, the harder it is to unwind. Catching up would require a bump in the outflow of cash the company simply cannot afford.

Here’s the rub. A similar flaw is deeply ingrained in software development. Projects rush to ship code, but defer documentation and skimp on testing. The code gets written, features go live, and stakeholders see progress. But the code has residual bugs, functionality has "quirks" and documentation is pushed to "later". Like stretching payables to buoy up the short term cash flow, software projects risk their long term future for the sake of short term convenience.

The longer this goes on for, the higher the cost of catching up grows. Untested code becomes harder to refactor, bugs accumulate in obscure corners, new developers struggle to onboard without clear documentation. Just like a business that cannot catch up with paying its suppliers, the project discovers that writing documentation and retrofitting tests across a sprawling code base becomes a disruptive burden it cannot afford.

In both cases, the deferred work is not just a delay, it becomes structural. The system becomes dependent on stealing from its own future. Reversing course takes more than effort, it requires a shift in priorities and a willingness to absorb short-term pain for long-term stability. 

The answer is not to see-saw through bouts of mad catch-up, but embedding discipline from the start. Pay suppliers on sustainable terms, document code while the knowledge is fresh, catch the bugs before releasing the new version. Once delay becomes dependency, the cost of reversal is no longer an accounting problem, it's endemic.