Software Performance Problems in New Zealand

Describe the slowness precisely

"The system is slow" gets you five quotes with five different assumptions behind it. Ten minutes of your own observation will make every quote sharper and cheaper.

Write down:

• What exactly is slow? One page, one report, everything, or the nightly job.
• How slow? Time it with your phone. "Eleven seconds" is worth far more than "ages".
• When? All the time, at month end, at 9am when everyone logs in, or only for the largest customer.
• Since when? Gradually over two years, or suddenly after a release in March.
• For whom? Everyone, one office, or people on a particular connection.

That last pair matters most. A sudden change points at a specific release. A gradual one points at data growth. They lead to different investigations.

Buy the diagnosis first

Nobody can price a fix for a problem they have not measured, and you should be wary of anyone who tries.

A diagnosis engagement — usually $5,000 to $15,000 — should leave you with:

• Measurements of the operations that are actually slow, not the ones people assume.
• The causes, named, in language you can act on.
• A prioritised list with an estimate and an expected improvement against each item.
• An honest statement of anything that would need structural change.

You keep that whether or not you use the same firm for the work, and it turns five wildly different quotes into five quotes for the same thing.

Be sceptical of hardware

The proposal to move to a bigger server is common because it is easy to write and easy to approve. It usually buys a few months.

A query that reads a million rows to display twenty is still reading a million rows on a faster machine. As the data grows the problem returns, and now you are also paying more every month.

There are legitimate cases — a system genuinely under-provisioned from the start, or one now serving ten times the users it was sized for. Those are identified by measurement. Ask to see the evidence before agreeing to spend money on infrastructure.

What it usually turns out to be

In ordinary business software, in rough order of frequency:

1. A missing index. Unnecessary at ten thousand rows, essential at two million. The cheapest fix there is.
2. A query fetching far too much. Loading every column and every related record to display a list of names.
3. Hundreds of small queries in a loop where one would have done. Common in code written quickly, invisible until the data grows.
4. A table nobody archives. Audit logs and event tables grow forever and quietly slow everything near them.
5. A report designed for a smaller company, recalculating from scratch what could be maintained incrementally.
6. Something external — an integration the system waits on, which is slow for reasons that are not yours.

None of these needs a rewrite. All of them are diagnosable in days.

Slow under load is a different problem

If the system is fine for one person and unusable for two hundred, the investigation changes. The causes there are locking, contention, connection limits and capacity rather than single-query speed, and profiling one user will find nothing.

Say so explicitly in the brief, because it changes who is right for the job. Ask each firm how they would reproduce the load — a proper answer involves generating realistic concurrent traffic, not clicking around a test site.

Insist on before-and-after numbers

Make this a deliverable, agreed in the quote:

• The same set of operations measured before work starts.
• The same set measured afterwards.
• Written down, alongside what was changed and why.

"It feels faster" is what you get when nobody established a baseline, and it is impossible to argue with or learn from. Numbers also let you run the same test in six months and see whether it has drifted back.

Then stop it happening again

Performance regressions are cheap to catch and expensive to discover. While a firm is already inside your system, add:

• Monitoring that records how long key operations take, so a slow release shows up in days.
• A performance budget — this page under a second, this report under ten — written down.
• A test that fails when the budget is breached.
• Archiving for the tables that grow forever.

None of it is expensive alongside work already happening, and it is rarely included unless you ask.

Comparing five quotes

Read for:

• Who insisted on measuring before proposing a fix?
• Who asked when it started and whether anything changed then?
• Who offered before-and-after numbers as a deliverable?
• Who resisted the hardware answer?
• Who included monitoring so it does not recur?

Describe what is slow, how slow, when it started, and who it affects. Developers who do this work will ask to profile before they price — and that is a good sign, not a delay.