The Law of Minimum Cost in software development relates to the financial cost, including time and materials, to complete a software development task.
The law states:
Every software development task has a minimum cost which covers the creation of code that functions well and is bug free.
The Law of Minimum Cost has a number of principles:
- It is hard to achieve the minimum cost.
- It is impossible to complete a task for less than the minimum cost.
- Costs will grow until the software functions well and is bug free.
- If defects and maintenance are ignored costs will grow via side-effects.
Good tech teams and companies aim to get as close as possible to the minimum cost of development. This can take time and will require good planning, code analysis, review, and excellent testing, all executed before code is pushed to production. These steps will reduce defect density and improve quality, which means a team will get closer to the minimum cost.
By contrast if a team rush tasks, cut corners and release code too early costs will spiral as they will have to fix bugs and faulty functionality which are in production. It will force the team to divert resources to maintenance and bug fixing which will reduce their efficiency. This will cause the company to hire more developers or wait longer for new functionality, and both will cost them financially.
There are also untracked financial side-effects caused by poor functionality and bugs in production. For example, they may result in fewer users interacting with the software, leading to fewer conversions. Or they may drive inefficiencies in other company departments which are reliant on the software. Overall the poorer the work and the higher the defect density the more costs will diverge from the minimum cost.
My advice generally is you cannot save money on a development task, you can only postpone the point at which you pay for it. I encourage all those involved in the tech industry to consider this before they plan their next development task or project.
Article Note: This 'law' has been working its way around my head for a couple of years. It comes from my experience as a developer and manager working with companies and clients who often try to cut corners in the mistaken belief it will save them money. My aim is to arm developers with language and concepts which will help them better communicate this and other fallacies to the business and commercial people they work with. I'd really appreciate your feedback on this as a concept.