Over the course of the Post Office Horizon trials, appeals and the Inquiry there was frequent mention of the KEL. Just exactly what is a KEL? Although this author has years of software development experience, it was not obvious. This does reveal one common problem, the use of internal (affectionate?) names for elements of the IT systems within Post Office, Fujitsu Services and others. Nothing wrong with doing this but they should have been used alongside professional and industry standard terms for those elements, making them have meaningful interpretations across the software development community.
The Inquiry did try to determine what this term means but their approach was to suggest a meaning and to ask the Fujitsu Services witness to confirm. The problem being that a possibly false interpretation was at large and people were getting excited over non existent problems.
People passionately wanted a historic list of bugs/problems and latched on to the KEL as being a part of such a list, unfortunately without considering that it may not be such a thing. This blog is being written after the author read the Post Office submission at the end of phase 7. Here they complained that all bugs were not disclosed to them, referring to “missing KELS”. Of course they were only missing if there was a presumption that the list of KELS was historically complete.
The KEL is a Fujitsu Services concept called the “Known Error Log”. Such a concept is well known globally by Software SUPPORT organisations and to a lesser extent by Software development organizations. It is a list of known errors and its purpose is to allow support and development personnel to identify problems that are known to exist and a fix is under development. What it usually is NOT is a list a of historic problems. The main purpose is to prevent wasted effort. Bugs should only be listed there if customers are likely to experience those problems with software that is currently in circulation. When a fix has been circulated there is no need to keep the entry in this log (an outsiders perspective, you can put whatever problems you want in this log but you should not be disappointed if it is not there).
How do we know this is the purpose of the KEL? The Inquiry called a Fujitsu Services witness to explain what it was! This witness was John Simpkins. John was a developer at one point, he claims, but then switched to Support. He seems to be quite an expert on the Horizon Software but he has not recently contributed anything to the codebase. You might think of developers akin to Barristers and support people akin to Solicitors but the analogy is poor. In general the Inquiry and the GLO focussed excessively on the Support organizations.
Who should respond to and maintain a list of problems? In most organisations this would be the development groups. They would maintain all the code for projects in something we call Source Control. They would maintain a complete list if problems. They would be the most important team to ask. The problem is that the Inquiry did not focus on them as a team. There were a couple of developers as witnesses but they were not interviewed in any depth. There was ample time but the session was closed early.
My suggestion is that there should be another evidence session where Fujitsu Services can explain their development process in great depth.