Developer says it is done but it does not work

If your developer says a feature is done and it does not work when you try it, the usual cause is that “done” was counted one layer at a time, such as the server, with no screen yet for the person who needs it. The first check is to ask to see a user doing the real job on a real phone or screen, not a tracker. In our case the tracker showed roughly double the real progress.

Here is how that looked at one business, and what fixing it took.

You were told the orders module was done. Your reps visit customers all day with a phone in their hand, and the whole point of the system is that they take the order there and then. A rep stands in a customer’s shop, opens the app, and cannot create an order. Not a rough version — there is no order screen at all.

Nobody had lied. The order module really was complete on the server: pricing, stock, numbering, permissions, forty automated checks. Every one of those things was true. What was missing was the one thing the rep needed, which was a screen.

The cost of this is not one screen. It is that the project’s progress tracker had been counting work like this as finished for months. When progress was worked out again by actually using the product rather than reading the tracker, the real figure was roughly half of what the tracker said. Plans and dates had been built on the comfortable number.

What was actually going on

Software like this is built in layers — the server, the web portal for the office, the phone app for the field — and the natural unit of a day’s work is one layer. Somebody spends a day on the server side of orders. That is a real day of work, and marking it done is honest about the day. It is wrong about the feature, because the person the feature is for has not got it yet.

The same shape turned up elsewhere once we looked. A sales pipeline had shipped as a complete server with no screens at all. Administration pages for roles and settings worked, but nothing linked to them, so nobody could reach them by clicking — which also meant nobody could test them.

Worse were the screens that looked finished and were not. Several lists in the office portal had a search box that accepted text and did nothing with it, because the server had no search for those records. An absent search box tells a user the capability does not exist. A box that does nothing tells them it exists and is broken — and they will use it, and trust results that were never filtered.

What we changed

The definition of “done” was written down and made to cross the layers: server, office portal, phone app, permissions, checks and translations, and a module is not done until a user can reach it. If the sentence describing what is finished does not have a person in it, it is not a completion report.

Progress is now measured by driving the product, and re-measured rather than accumulated. A tracker records the last thing somebody said. Using the application records what is true. The seeded demo data turned out to be missing a price list, which meant every attempt to create an order was rejected — invisible to every automated check, because the checks made their own data.

The search boxes that did nothing were removed rather than left in place, and the roughly fifteen gaps on the server that they had been papering over were written up as work to do. Where a screen could not honestly show what its heading promised, it was relabelled to say what it actually shows — a payments panel that could only show customer-level figures says so, rather than implying it is per order.

And the office portal’s list screens were brought up to one standard in a single pass rather than piecemeal: sorting only on columns the server actually supports, pickers instead of raw ID boxes, actions that respect what each record is — an order is a workflow and does not get an edit button, an invoice can be edited only while it is a draft. Nineteen browser pop-up confirmations across the product were replaced with a proper component, which sounds cosmetic and is not: a native pop-up cannot be translated or show progress, so every destructive action had been untranslated and silent while it ran.

What it did not fix

None of this is a tool you can buy. It is a definition of done that the person paying for the work has to insist on, and a habit of measuring progress by using the thing rather than reading about it. The tracker did not become accurate; it became something to check against the product, which is the most a tracker can be.

How to check real progress yourself

1. Ask to see a person doing the real job from start to finish, such as a rep taking an order on a phone, rather than a status report.
2. Ask where each finished item lives: the server, the office portal, the phone app. A module is done only when a user can reach it by clicking.
3. Look for controls that do nothing. A search box that accepts text and ignores it is worse than no search box.
4. Try it on demo data you did not see being prepared. Ours lacked a price list, so every order was rejected, and no automated check noticed because the checks made their own data.
5. Measure progress again each time by using the product, not by adding up reports.

Where this ends up

A rep with a phone in a customer’s shop is the point of a field-sales product, which is why Sazinga Field treats the order taken there and the order the office sees as one record, rather than as two features on two layers.