"It's Just a Small Change": The Most Expensive Sentence in Software

A client looks at the customer screen and asks you to add one field: a second phone number. "It's just a small change," they say, and on the screen they are right. One label, one text box, an hour of work.

Then the field starts to travel. It needs validation: which formats, which country codes, and is it required? It needs a database migration, and someone has to decide what the existing customers get in the new column. It may belong in the monthly report, and in the export a partner imports every night. The mobile app has to show it, and last year's version of the app, still installed on plenty of phones, has to keep working without it. If the interface ships in Arabic and English, the label exists twice and the layout has to work right to left. Tests change, the help page changes, and support needs an answer for the customer whose courier called the wrong number.

None of that is gold-plating. It is what "add a field" means once the field is real. "Small" describes the request as it looks from outside. The cost lives in everything that depends on it.

Why the sentence is expensive

The person saying it is usually sincere. They see the screen, because the screen is the part of the system they use. The reports, the integrations and the old app versions are invisible from where they stand, so the sentence is a fair description of what they can see.

The sentence does its damage before anyone has looked at the system. It sets a size, and the size becomes the expectation. If the work then takes two weeks, the team looks slow. If the team pushes back, it looks defensive. Neither is fair, and both cost trust.

It also repeats. One small change is rarely the problem. Ten of them in a quarter, each agreed on the spot, is how a project ends up late without anyone being able to name the decision that made it late. Every request was small. The total was not, and nobody was asked to approve the total.

Hyrum's law: somebody depends on it

Hyrum Wright, an engineer at Google, drew an observation from years of infrastructure migrations, where the simplest library change could break a system far away. Titus Winters gave it a name, Hyrum's law, and Software Engineering at Google (2020), the book the two wrote with Tom Manshreck, states it like this: with enough users of an API, "all observable behaviors of your system will be depended on by somebody."

For one new field, the observable behaviours are easy to list:

• The export's column order. Nobody promised that the email address is the seventh column. A partner's import script reads it there anyway. Insert the new phone column after the first one, and tonight's import fills their email field with phone numbers.
• The shape of the API response. Adding a field is backward compatible on paper. A client that rejects unknown fields disagrees.
• What "required" means. Make the field mandatory on the server, and every old app version that cannot send it stops saving customers.
• The report's totals. If the new number changes how duplicate customers are matched, this month's figures stop agreeing with last month's, and finance notices first.

That is the technical half of the answer to "why does it take so long?" The edit is small. The number of things that can see the edit is not.

You cannot stop people depending on what they can see, but you can choose what they see. Exports with named headers survive a new column. Clients that ignore fields they do not know survive a new field. A new field can start optional and become required once the old app versions have gone. Each of these makes the next small change cheaper, which is the only way a small change ever becomes small.

Answer with consequences and options

The hard part is saying this without sounding as if you are refusing. "That's not small" starts an argument about size. Consequences and choices start a conversation about priorities. Something like this:

"Yes. On the screen and in the database, this week. In the monthly report and the partner export, two more days, because the partner has to change their import as well. In the mobile app, with the next release. Which of those do you need first?"

That answer agrees to the request, shows the ripple, and hands the trade-off back to the person who owns it. Often the reply is "the screen, for now", which is a smaller change than the one you were about to build.

Knowing why the client wants the field shrinks the ripple further. If the second number exists so couriers can reach someone at the door, it has to reach the courier's app, and the monthly report can wait. That is the question from Show Me the Money!: what job does this do for the customer? And when a question such as "is it required?" gets a nod in a meeting, check what each person meant, because agreement in a meeting is not shared understanding.

A ripple checklist

Before you say yes to a "small" change, walk it through this list. Most lines take a minute to rule out. The one that does not is the one you needed to find.

1. Input: who enters it, which values are valid, and is it required?
2. Storage: what migration does it need, and what do existing rows get?
3. Access: who may see or change it, is it personal data, and is the change audited?
4. Outputs: which reports, exports, emails, documents and dashboards show it, or should?
5. Interfaces: what changes in the API, in older app versions, and in every integration that sends or receives this record?
6. Language: labels, messages and layout in every language the interface supports.
7. Proof: tests and test data, documentation, and what support should tell a customer.
8. Decisions: who answers each open question, and by when?

The list is not there to make the estimate bigger. It is there so that the estimate and the change are the same size.

Next time someone says "it's just a small change", hear it as a description of the screen. The real size of a change is the number of things that will notice it.

Written by Eslam Hamed, a Technical Lead and AI Solutions Architect working on enterprise software delivery, from pre-sale to handoff.