Most business-critical software does not begin with somebody saying, “We’re going to build a business-critical system.” It usually starts with something much smaller. A spreadsheet is becoming difficult to manage, a departmental form needs digitising or a handful of engineers need a better way to record their work.

It is easy to think of software used in the field as an office process running on a phone. In an office, the environment is usually predictable. The user has a reliable connection, a full-size screen and time to deal with something if it does not behave as expected. Someone working in the field may be in a plant room, on a construction site, beside a road or inside a building where the signal disappears completely. They may be wearing gloves, working in poor weather or co

Low-code has changed application development enormously, but I sometimes think the name gives people the wrong impression. It can sound as though much of the work involved in creating an application has disappeared when, in reality, a lot of it has simply changed.

One of the odd things about software is that the screen often tells you surprisingly little about the system behind it. Two engineers can be standing on different sites looking at applications that appear to do almost exactly the same thing. Both have been given a job, both complete a form, both take photographs and both submit a record back to the office. From their point of view, the experience may be almost identical, even though the organisations they work for have take

Give a developer a problem and, quite naturally, they start thinking about how it could be solved: what data is needed, what the screens might look like, how the process should flow and what should happen at each stage.