Error-free Key Performance Indicators

There has been a certain amount of “empassioned negotiation” at The Office™ regarding what exactly constitutes “error-free” deliverables and what the implications of the words “error-free” are on key performance indicators in an employment context.

It is entirely reasonable that a company should expect you – whether you are employed as a full-time developer or as a contractor – to write code that is robust, clean, best-practice and easy to maintain. It would ordinarily be a matter of personal pride that a developer would produce code that exemplifies the best standards in software development. But what happens when, in the process of committing these expectations to paper, your employer includes the phrase “error-free” as part of your performance outputs or criteria? What are the implications?

“Error-free” is a highly subjective term and one that is open to a lot of interpretation by either party. While the employer might expect that the software you deliver should work flawlessly in the production environment, the developer might – very naturally – approach the condition from a much more technical and literal frame of view.

Let’s look at the two opposing points of view and discuss the issues surrounding each. First – your employer.

The employer’s expectation around error-free is that the code should, naturally enough, be fairly watertight. It should be of a standard that, once deployed into a production environment, it runs seamlessly and flawlessly. Any unexpected situations should be handled elegantly and the user experience should be completely fluid.

When the company refers to “error-free”, its actual expectations are primarily about deliverables: is the availability and continuity of the system upheld by the code you’ve released; does the code meet company standards for maintainability and general best-practice; and of course is it delivered with minimal impact to deadlines and cost?

Assuming these criteria are met, in most ordinary cases, you will be deemed to have fulfilled your role. So then, what of the developer’s interpretation?

The developer by nature will approach the problem from quite a different mindset. To someone who deals with logical absolutes and literal interpretations, error-free means exactly that: eliminate all possible errors from your code. The developer will go to great lengths to ensure that every possible eventuality – no matter how unlikely – is considered and handled. This degree of exception handling would add a significant amount of time and effort to any development project. Meeting a client’s delivery dates and functional requirements becomes that much harder and more stressful as the developer tries to meet the conflicting expectations of client and employer by providing a completely fault-tolerant and specification-perfect deliverable on time and on budget. A goal highly unlikely to be achieved.

So how much of a problem is this in reality? How literally should the developer realistically interpret the phrase “error-free”? Let’s assume that performance reviews contain some clause that reflects an expectation of error-free. Now assume that a new web application is deployed to a production environment. All goes well until the database server unexpectedly fails for some unrelated reason. The web application cannot make a connection and the site fails; redirecting the user to the Error page. Now the error is not with the code, but none-the-less, an error has definitely occurred. While any reasonable employer should agree that the fault does not necessarily lie with the developer, the developer has still failed to provide an error-free deliverable.

Another example might be if bad data is imported into the database that is depended on by the web application. The bad data then causes some pages to fail catastrophically and reports to display incorrect information. Again – who is to blame here?

Let’s look at another possibility. Assume that the web application runs perfectly all the time. The user is never aware of any faults and, despite perhaps being a little sluggish in some aspects, the overall experience is very favourable. However, upon opening the solution up and viewing the code, a new developer to the team discovers classes full of declarations such as this:

        public DataTable getDataTable(string product, string period)
        {
            string myDate = period;
            ...

The code makes no use of any standard object-oriented principles – there are no interfaces, dependencies are tightly-coupled and methods doing the same exact task are repeated in several different places. Try / catch blocks wrap around large swathes of code and do nothing with the exception:

            try
            {
                // Carry out a whole bunch of operations
            }
            catch (Exception e)
            { }

Now how error-free is our application? Granted there are no visible errors from the user’s perspective, but imagine the veritable minefield of problems our developer faces. So if the code works, is it really error-free? Who should be the judge? If the client is satisfied that everything is fine and the employer is blissfully unaware of the litany of bombshells then would the developer be judged to have fulfilled the obligations expected of their role? In reality, errors have been growing organically in the code base for who knows how long but never brought to the attention of non-technical management who can see and understand only the functional behaviour and visual design and how these meet the specifications.

When all is said and done, the inclusion of an expectation of “error-free” code is either idealistic folly on the part of the employer and in effect an unattainable and unrealistic goal to set, or it is a millstone for the developer’s neck that brings little-to-no value for the client given the time and effort invested in order to achieve it. No code base is ever truly error-free. It is impossible to accommodate every outcome and foresee every event and expecting the developer to do this is unreasonable; pointless at best.