Why Small Software Changes Blow Up
Where does the money go?
In my previous article, it’s a simple change, why isn’t it done yet? We discussed the reasons why code and features can take a long time to be available to the business and why this creates hidden costs.
Today, we shall follow one apparently simple change and show where the extra time and cost come from.
The “One-Line Change”
Let’s take a real-world example involving currency rounding.
Imagine a payment system that can already handle cross-currency, and Japanese yen is to be added to it.
Converting British pounds into Japanese yen:
£10.53 = ¥2,000.70
JPY has to be recorded as a whole number. The system, therefore, needs to decide whether ¥2,000.70 should be rounded to ¥2,001 or ¥2,000, based on the correct rounding rules.
Simple.
Great Expectations
From a business perspective, the request appears straightforward.
The payment system already handles conversions. All that needs to happen is to grab the conversion rate and round the result.
The expected work might look like this:
One mid-level developer makes the change in one day.
One QA tester checks the payment flow in one day.
The change goes into the next routine release.
Using current UK salary estimates, the approximate employment cost would be:
Mid-level developer: 1 day × £290 = £290
QA tester: 1 day × £225 = £225
Expected total cost: approximately £515
For context, the following estimates are also assumed later in the piece:
Junior Developer: 1 day × £160 = £160
Senior developer: 1 day × £340 = £340
These figures are illustrative rather than a quote. They include salary, employer National Insurance, and a minimum employer pension contribution. They do not include equipment, software licences, management time, office costs, recruitment, training, or other business overheads.
At this stage, the business expects a small change with a clear cost: around two working days, which would cost just over £500.
So, How Does This Go Wrong?
In our example, we needed to add support for JPY rounding.
This became more complicated when we found two separate places in the system handling currency rounding. At first, they appeared to do the same thing, but there were subtle differences in how they handled certain edge cases.
On top of that, some payment flows included a 2% currency conversion fee.
A simple rounding change suddenly had a lot of moving parts.
Before changing anything, the team first needed to understand why the current system had been built this way:
Why did both versions exist?
When was the conversion fee applied?
Could the two versions be safely merged into one place?
They then needed to establish whether changing the structure would create new problems:
Would changing one version leave the other behaving differently?
Could the rounding be handled in one place within the current system?
Were there any unit tests covering the existing behaviour?
Finally, they needed to understand how the change would interact with the wider currency logic:
How did the different currencies and currency conversions interact with both versions?
Would any of those calculations be affected by the change?
This is where a task that looks simple from the outside can start taking days.
The time required will depend on the size of the system, the complexity of its business rules, how well the code is structured, and how familiar the team is with that area.
If the people who originally built the system have left, the current team may need to work out why decisions were made before they can safely change them.
In this example, let us allow three days for investigation, including trial code changes and testing:
Developer investigation: 3 days × £290 = £870
Running cost: £870
The team has already spent more than the original expected development and QA cost, and no change has yet been released.
Further Complications
Finding the calculation is only the beginning.
The team must then understand everywhere each calculation is used.
The currency logic might directly affect:
Customer payment pages
Admin tools
Refunds
It may also influence other customer and financial processes:
Cancellations
Invoices
Reports
The impact can then extend beyond the main application:
Background processes
Emails
Accounting systems
It may even affect systems outside the immediate codebase:
Other services or APIs
This matters because the same method may be used differently in different parts of the system.
For example, the customer payment page might need to round a JPY total after applying the conversion fee. An admin refund process might use the same calculation but apply the fee at a different stage.
Changing the shared method could fix the customer payment while making the admin refund incorrect.
The team cannot safely judge the task by looking only at the page where the original problem appeared. They must trace the calculation through the wider system and understand how each area expects it to behave.
Let us add:
Developer impact analysis: 1 day × £290 = £290
Senior developer review: half a day × £340 = £170
Additional cost: £460
Running cost: £1,330
Implementation Terror
After the investigation and impact analysis, the final code change may still be small.
The team might make a limited change:
Change a single line
Add a currency check
Create a small rounding method
Alternatively, they may use the opportunity to improve the surrounding structure:
Remove duplicated logic
Move both calculations into one safer shared location
Add handling for the conversion fee and other edge cases
They may also add automated tests to make future changes safer.
The quickest option may be to change one line and leave the rest of the system alone.
The safer option may be to remove the duplicated behaviour and make sure every payment flow uses the same calculation.
That creates an important choice: make the smallest possible change now, or spend slightly longer reducing the risk of the same problem returning later.
Let us allow one day for implementation:
Developer implementation: half a day × £290 = £145
Running cost: £1,475
The code itself may only take a few hours. Most of the cost so far has come from understanding what the change needs to do and where it can be made safely.
Problems With Testability
At this stage, the obvious response is:
“Add an automated test to prove the rounding works.”
That sounds simple, but it depends on how the existing code was built.
There may be no tests around the payment calculation. The business logic may be mixed directly into the payment page, connected to a database, or dependent on an external service.
If the calculation cannot be tested on its own, the team may need to refactor the code before a useful test can be written.
The business is therefore not only paying for a test. It may also be paying for the structural work needed to make testing possible.
The team could choose to minimise the immediate work:
Make the change without strong automated test coverage
Rely more heavily on manual and integration testing
Make a limited change now and plan wider improvement later
Alternatively, it could invest more time upfront:
Refactor the code so the calculation can be tested properly
Saving costs down the line when this code is revisited
For this example, let us assume the team decides to separate the rounding logic and add unit tests:
Developer refactoring and tests: 2 days × £290 = £580
Senior developer test and code review: half a day × £340 = £170
Additional cost: £750
Running cost: £2,225
Finally, QA Gets Involved
Automated tests can prove that the rounding method behaves correctly when tested on its own.
They cannot prove that every part of the wider payment system still works.
QA should now test the system as a whole. Including but not limited to:
The new GBP-to-JPY conversion
JPY payments throughout the system
Existing currency conversions to ensure they still behave correctly
Payments with and without the 2% conversion fee
Customer payment journeys
Admin payment and refund journeys
Cancellations
Invoices and reports
Edge cases around JPY currency handling
Other areas using the same currency calculation logic
This wider checking is called regression testing. It means confirming that features which worked before the change still work afterwards.
The larger and more connected the system is, the wider this testing may need to be.
A one-line change can therefore require several days of QA because the impact is not limited to the line that changed.
Let us add:
Initial QA and regression testing: 3 days × £225 = £675
Developer fixes following QA: 1 day × £290 = £290
QA re-testing: 1 day × £225 = £225
Additional cost: £1,190
Running cost: £3,415
The Unexpected Introduced Issue
Even after careful investigation and testing, the team may find that the original business rule was not as simple as expected.
For example, the existing system may contain historic or external dependencies:
Existing transactions may use the old rounding behaviour
A third-party accounting system may expect a different value
Refunds may need to match the original payment exactly
Other differences may only appear when the wider payment flows are compared:
One payment route may apply the conversion fee before rounding while another applies it afterwards
Historical reports may need to preserve their existing results
Each newly discovered difference creates another cycle of work.
The team must first understand and correct the issue:
Analyse the problem
Adjust the code
Review the change
It must then prove that the revised solution works:
Test it again
Send it back through QA
For our example, let us allow:
Developer rework: 1 day × £290 = £290
Senior review: half a day × £340 = £170
QA testing: 1 day × £225 = £225
Additional cost: £685
Running cost: £4,100
It Is Released!
The development work may now be complete, but that does not mean the change is available to customers.
Before release, it may still require:
A final code review
Approval from the business
A pull request to be completed
The change then needs to be prepared and checked in a release environment:
Deployment to a staging environment
Final checks in staging
Release notes
Finally, the production release itself needs to be controlled:
A planned release window
Monitoring after release
A rollback plan in case something goes wrong
The timing of the release also matters.
The task may have sat in the backlog before work began. It may then consume a large part of a sprint, wait for QA, and miss the next scheduled release window.
A change that takes one or two weeks of effort could therefore take several weeks to reach customers.
While this happens, other work is pushed further down the backlog.
Let us add half a day of senior release support and half a day of QA checks:
Senior release support: half a day × £340 = £170
QA release checks: half a day × £225 = approximately £113
Additional cost: approximately £283
Final illustrative cost: approximately £4,383
The business originally expected the change to cost around £515.
In this theoretical example, it instead costs approximately £4,383. That is nearly nine times the original estimate.
The business has paid more than £4,000 for one line of code.
It has paid for the investigation, analysis, implementation, testing, review, rework, and release activity needed to change that line safely.
The Impact
The cost of this change does not stop at the £4,383 spent delivering it.
It also takes around 14 working days to move from investigation to release. During that time, the rest of the development team continues working on other tasks.
Let us imagine a six-person team made up of:
Three mid-level developers
One senior developer
One junior developer
The sixth team member is the QA tester supporting the work being completed across the team.
Using the same illustrative daily employment costs as before:
Three mid-level developers: 3 × £290 = £870 per day
One senior developer: £340 per day
One junior developer: £185 per day
One QA tester: £225 per day
Estimated team cost: £1,620 per working day
Across the 14 working days taken to investigate, implement, test, and release our supposedly simple change:
£1,620 × 14 days = £22,680
This does not mean the business has wasted £22,680. Each developer is working on a separate task, and the QA tester is supporting work across the team.
However, it shows the scale of the development budget being committed during the same period. Think how much more they could do with a resiliant well organised system.
If the rest of the team is working in the same difficult codebase, the JPY rounding change may not be the only task expanding beyond its original estimate. Other developers may also be spending extra time investigating unclear logic, testing connected areas, and dealing with unexpected consequences.
The result is felt across the roadmap:
Fewer tasks are completed within the sprint
Important features remain in the backlog
Planned release dates begin to move
As the delays continue:
Forecasts become less reliable
Stakeholders become frustrated
The team spends more time explaining why the work has slipped
The business may then miss opportunities because useful features, customer requests, or revenue-generating improvements are delivered later than planned.
The true cost is therefore not only the £4,528 spent on the rounding change.
It is also the wider development capacity being consumed, while avoidable complexity slows down work across the team.
A business spending more than £22,000 on its technical team over this period should expect that investment to create meaningful progress. When the codebase makes every change harder than it needs to be, more of that budget is spent managing complexity, and less is spent moving the roadmap forward.
Warning Signs of a Wider Problem
One difficult change does not automatically mean the whole codebase is a problem.
Software work can be unpredictable. Business rules can be complex, and some tasks will naturally take longer than expected.
The concern is when the same pattern keeps repeating.
You may have a wider codebase problem if:
Small changes regularly take much longer than expected
Estimates vary greatly because the impact is unclear
Work repeatedly moves from one sprint to the next
The development team may also show signs that certain areas have become difficult to work with:
Developers avoid or are cautious around particular parts of the system
Nobody can clearly explain how important areas work
The same bugs keep returning after they appear to have been fixed
Testing and releases can reveal the same problem:
QA repeatedly needs to test large parts of the system
Releases create issues in seemingly unrelated areas
The team spends more time investigating and fixing problems after release
Adding more people may increase the amount of work completed, but it does not necessarily reduce the cost of each change.
If more developers are hired and delivery still remains slow, unpredictable, or expensive, the issue may not be the size of the team.
It may be the system they are working in.
One difficult task may be normal.
A repeated pattern suggests that the codebase itself may be creating extra cost across the wider roadmap.
What can be done about it?
The good news is that these problems can be improved without rebuilding the entire system.
The aim is not to fix every technical weakness or create a perfect codebase. It is to identify the areas creating the greatest cost and risk, then improve them in a controlled order.
That may involve:
Identifying the workflows that consume the most development and QA time
Improving automated test coverage around high-risk behaviour
Separating tightly connected parts of the system
Other changes may focus on simplifying the code itself:
Removing duplicated business logic
Refactoring the flows that repeatedly cause bugs or delays
Creating clearer boundaries between different parts of the system
The release process may also need attention:
Improving deployment checks and monitoring
Making changes easier to release and roll back safely
Modernising the system gradually rather than through one high-risk rewrite
In a healthier system, a change like our JPY example would be easier to locate, safer to test, and less likely to affect unrelated areas.
The next article in this series will look at how to improve difficult software without rewriting everything, including how to decide what to refactor, replace, isolate, or leave alone.
How CodeOptimo helps
When small software changes repeatedly become large and expensive pieces of work, putting more pressure on the technical team rarely solves the underlying problem.
The first step is to understand where the additional time and cost are coming from.
A Codebase & Architecture Audit can identify:
Where development time is being lost
Which parts of the system create the greatest risk
Which technical issues are increasing delivery costs
It can then establish what should be improved first, what can safely wait, and what does not need to be changed at all.
If small software changes are repeatedly becoming large, expensive pieces of work, a Codebase & Architecture Audit can help identify where the time and money are being lost.
