Software Design

Now, there’s been a few column inches about software design. What more is there to say?  Quite a lot actually, and it concerns the whole way it is done.

To clarify up front, I’m talking about stuff designed to help in the real world, like an account opening process for a bank, or a recruiting application for, say, the Ministry of Defence (just sayin’), not some hifalutin’ AI code.

Typically, in these real world circumstances, the software is designed to speed up/lower the cost of something that already happens, something that involves a number of existing departments. So, the first mistake is to try and build something around that existing infrastructure: it the case of an account opening system, a complex workflow that bounces the process into the inboxes of different sub organisations, like some sort of pinball machine. This is akin to putting a saddle into a car. With modern tech, you need to think hard about its potential to change how things are done fundamentally. What you soon realise (spoiler alert) is that the software can do vastly better what you had to use departments for in the past. So, rather than information bouncing around the fixed points of a company organogram, it is the information that is fixed, and the people cluster around it when required. Of course, this mistake is often made as the organisation lacks the political mandate to change the way things are done across departments, forcing the poor old IT guys to duly build the saddle in the car.  So what?  Well, it almost never works, and it costs the earth. Apart from that, it’s fine.

The second mistake is that software is designed by lawyers to prevent the worst from happening, rather than to help the best to occur. There are many reasons for this, not least it is vastly easier to quantify a potential lawsuit that the effect of making a user’s day a little bit more whole.  How does this manifest itself?  For instance, in a recruiting system, it can be the prioritising of the ability to capture and retrieve a full audit trail of an interaction with a candidate, over the actual experience of that candidate when applying using the system.  Again, it is difficult to blame the techies, who can only code against the brief they’ve been given. A particularly unhelpful complication in these things is the existence of an outsourced partner, whose priority is not the experience of the candidate, but the avoidance of penalties under their contract. So what? Well, recruitment is a process of attraction. Thus you need to make the process attractive. You only have to see the car crash that is the Army’s recruitment efforts to see how damaging this backside-covering has been.