Most defects in a bespoke system are found only once it is in use. There is one category, though, that you can check yourself before the building starts, and it costs an afternoon: lists of permitted values. Nationalities, legal forms, tax rates, units, statuses, document types. Things that look like a formality and decide whether you can enter into the system a person who actually works for you.
When somebody does not fit into such a list, the process does not slow down. It stops. The record cannot be saved, so it does not exist, so nothing else can attach to it: contract, payroll, timesheet, invoice.
What it looks like when it happens
January 2024, the internal system of a staffing agency. The system was in use and people were working in it. The first long list of comments from a user arrived on 12 January 2024, and four of its six items were one and the same defect, just on different people:
"cannot enter nationality SVK"
and the same sentence for Hungarian, Bulgarian and Azerbaijani nationality. The list existed, the interface worked, the form behaved exactly as specified. It simply did not hold the values the agency needed every week.
A second group of comments from the same day concerned worker accommodation: staff were registered to rooms, but the number of beds and free places did not add up. The same type of defect one floor up - the records described a different reality from the one in the building.
An acceptance test would have found neither. At acceptance you enter a model person, and that person is always from the country somebody thought of.
Why acceptance misses it and the first week of use finds it
Acceptance is done on whatever is at hand, and that is usually a clean, representative case. Real use starts with the exceptions, because exceptions are exactly why people reach for the system.
The difference is also in who is at the keyboard. At handover the data is entered by someone who knows the specification. In use it is entered by someone who knows the reality, and who runs into the places where specification and reality parted ways. That is the only moment the gap shows, and it is also the most expensive one: the system is paid for and people have already moved their work onto it.
Which is why one thing is worth doing the other way round from the usual: give the supplier the exceptions first, not the model case.
Nine lists to go through before you commission the work
You do not need a technical person for this. You need someone who works with it every day, and an hour of their time.
- Countries, nationalities and identity documents. Not only EU states. This includes people whose document does not have the structure you expect.
- Legal forms of your customers. Company, sole trader, association, public body, a foreign entity with no local registration number.
- Tax rates and regimes. Including the ones you use three times a year.
- Units and their conversions. Piece, pack, pallet, metre, hour, and what happens to a decimal.
- Record statuses. How many there really are and which one means the end. There are usually more statuses in people's heads than in the specification.
- Capacities and locations. Rooms, warehouses, racks, vehicles. A test question: do you have a location numbered zero, or one with no number at all?
- Names and addresses. Diacritics, apostrophes, two surnames, an address with no house number, a foreign postcode.
- Phone numbers and identifiers. With a country code, without one, with spaces.
- The calendar. Part-time contracts, shifts across midnight, the last day of the month.
Each item comes with a single question: write down three values that have to be in that list and are not obvious. Whoever works with it will write them in a minute, and those three values are usually exactly what the system is missing.
Two decisions that belong in the brief, not in the code
Who may change the list. When the list is locked in the code, every new value means a request to the supplier, a wait and an invoice. When it is editable in the admin, it is changed by the person it concerns, at the moment they need it. The difference in the cost of delivery is small. The difference in the cost of running it is decisive, and it only shows up a year later.
What the system does with a value it does not know. There are two legitimate answers and each fits somewhere different. Either it rejects the record, because a wrong value would cause damage further down the process, or it accepts it with an "other" option and free text, so the work can go on and the value is filled in later. The worst is the third variant, the one that appears when nobody decides: the user picks the nearest wrong value because they need to save, and from that moment the system holds numbers that cannot be trusted.
What this means for automation between systems
A list of values is not only a matter of the form. The moment data travels between two systems, it is an agreement about translation: what a value sent by the other side means at your end, and what happens to a value you have no translation for.
In practice that means three things. The mapping table belongs where the commercial side can change it, not in the code. An untranslatable record waits in a queue rather than being created blind. And somebody has to find out that the queue is not empty, otherwise it is just a quieter way of losing data.
Want to go through that list with people who build bespoke systems
Send us a list of your categories and three values for each of them that are ordinary to you and surprising to an outsider. We will send back where a defect arises from them that acceptance will not catch.
Systems where lists like these are part of the brief are what we build under CRM and business systems; connecting systems that already exist comes under business process automation.
Write to info@lamapixel.com or call +420 775 599 009.
