My entire career as a software engineer I have constantly debated the idea of key performance indicators (KPIs) and how these are applied in software engineering. In my experience, most tech based companies use a generic KPI model to the measure the performance of their software engineers. Measuring the performance of software engineers is almost as challenging as keeping up with the latest changes in technology. There are many reasons for this, from the type of software created to the type of problems that are solved. When I started out in high school writing Turbo Pascal, success was measured by the number of lines of code our programs had. The more code you had the better your program was, 10000 lines of code (LOC) meant bragging rights.

In the real world, no one cares about the number of lines of code anyone writes. This measurement, if still being used, is pointless. So if we can’t use LOC, then how about the number of errors and/or exceptions the code produces? This has proven to be a pointless metric with many compilers, IDE’s and tools performing the analysis and allowing software engineers to avoid simple errors. Searching through job ads, many list criteria such as attention to detail, problem solving and team work as characteristics needed or required to apply for the job. However once the software engineer has the job, how do we measure their performance against meeting these criteria?

First we need to find out what performance measurements we require. A number of advocates for key performance indicator(s) (KPI) specify the use of the S.M.A.R.T criteria to determine KPIs. The acronym specifies that KPIs need to be Specific, Measurable, Assignable, Realistic and Time based. But using these criteria do not translate to KPIs directly related to the process of software engineering.

For instance, what Specific metric could we use in software engineering? The creation of software crosses many boundaries, we all work on different domains, architecture and languages. Similarly, what measurement could we use to evaluate a software person’s ability? With such a broad range of software platforms and skills, drawing up KPIs to be Measurable is difficult. What are the KPIs that are Assignable to a software engineer? Considering that these KPIs need to be attainable. There is constant change in software engineering, what is relevant today is not that relevant in the next performance review. Often companies ask for the impossible to be done. Have you experienced a project timeline being shifted to something unattainable. KPIs that are not realistic or have an overreaching trend to push engineers to move out the door.  How do we create Time based KPIs for a software engineer? As I mentioned, constant change within software engineering introduces difficulty in selecting KPIs.

Establishing KPIs to a particular environment requires a holistic approach, encompassing factors which are easily adaptable between different engineering environments. A holistic approach would have to be concerned with what the most prevalent software engineer’s deliverables. These deliverables are constantly debated in tech talks and software authorities. One of these that have been regularly commented on is bad code. Uncle Bob (Robert C Martin) explains why bad code is so bad for software.

As a software engineer, I have worked on legacy and new systems that suffer from bad code. This ultimately affects code quality. Producing quality code not only benefits the engineering team but the entire organization and its’ products. Using code quality as a factor we can abstract Quality as a holistic criteria of a Specific, Measurable, Assignable, Realistic and Time based KPI. Although I am certain that most engineering teams advocate for code quality, additional factors can be added to this criteria depending on the engineering team and their outlook on producing Quality. In order to produce quality code, engineers would first need to have an Understanding of what is required in the domain in which they engineer solutions for. Without this Understanding, Quality is impacted due to an incorrect interpretation of the requirements, potentially leading to projects being jeopardized.

Understanding leads to Innovation. By understanding the domain in which the engineer practices their skills, quality coding fit for purpose could drive Innovation for the organization. This could be achieved by solving the problems unique to each domain. In order to establish Quality, Understanding and Innovation, software engineers are required to have a certain level of Commitment towards achieving the goals of the organization. In various engineering methodologies, each advocate for a software engineer to commit to a goal. Committing to these goals is vital to getting the work done and to the success of projects. Enhancing ones Knowledge leads to better understanding, quality, and innovative ideas giving engineers the confidence to commit to goals. By increasing ones knowledge base, an engineer can help drive innovation through new skills, techniques and technology learnt. This in turn drives Quality and Understanding.

The Q.U.I.C.K. framework for KPIs does not mean to be prescriptive. Each of the criteria, Quality, Understanding, Innovation, Communication and Knowledge can have several factors listed for each. These factors help to establish if an engineer is accomplishing Q.U.I.C.K. criteria. A simple guide to record the metrics of each of the factors related to the criteria is presented in this excel document. I have presented some of the factors I have found relevant in my working environments.

I hope that this attempt at a KPI framework for software engineers is seen as a stepping stone to establish KPIs that are relevant to the engineering of software.