This is an interesting topic that may actually be controversial to some readers, since it seems to chip away at a standard, accepted practice in software development: the use of metric-based Key Performance Indicators (KPIs) to evaluate the performance of a developer.
What does KPI mean?
By definition, a true KPI is more than just a metric or statistic. It’s more than a comparison of statistics over time.
A true KPI is an established SMART goal related to a specific metric that is focused on maintaining or improving performance in a given area.
So, for example, many companies hiring a web developer may be rightfully concerned with the number of errors that developer’s code contains throughout the development process. In this case, during the hiring and subsequent evaluation process, here are three possible ways the company could look at that metric:
- We want less than 25 errors per release.
- We want 10% less errors per release over ten weeks.
- We want the error rate to rise no higher than 10 errors per thousand lines of code in each release.
In this case, only the third option can be labeled as a true KPI, since it is both specific, measureable, and goal-oriented. It can be effectively monitored in conjunction with the cadence of the development process (based, in this case, on release dates) and can easily be reported on.
The other options, while probably making sense to the client, are unfair to the developer and/or not specific enough to be effectively measured and evaluated with any consistency.
Why KPIs are a good idea
To begin, I want to make clear that I’m definitely in favor of monitoring and evaluating your web developer’s work against set standards to ensure you’re getting adequate value for your money. That only makes sense, both from a business perspective, and in terms of the level of trust that’s necessary for an ongoing development partnership to succeed.
I regularly experience both sides of this equation as the president of a web development firm that works with a number of both staff and freelance developers both onshore and offshore. As the head of the organization, I am generally the face of the firm and deal primarily with the clients directly. So, when it’s time for my clients to evaluate how we’re doing, it’s me who gets to sit in the hot seat.
At the same time, I also need to continually evaluate those developers I work with to make sure they’re offering the quality I need for my clients at a price that’s sustainable for my business.
So, without a doubt, some sort of established criteria against which we can evaluate performance is vital to the success of a development program.
Where KPIs fall short
The trouble I most often find with standard KPIs as applied to web development is that companies or individuals who are requesting development help may or may not have any real experience or knowledge in how the development process works or access to any sort of industry benchmarks, which means the KPIs they come to the table with are often either unrealistic, or not real KPIs at all.
They may be based on unrealistic expectations (i.e. insisting on zero errors) or be completely arbitrary (no more than 10 errors), and therefore ineffective as evaluation tools.
Or, for the same reasons, they may be wholly unacceptable as measurements of quality. For instance, if a company with no development experience hires a developer and hands them a list of requirements that includes “no more than a 75% error rate will be deemed acceptable,” they’re going to be scraping the bottom of the quality barrel without even realizing it.
Another problem is focusing on the wrong KPIs for a given project.
For example, KLOCs (thousands of lines of code) used to be a popular KPI to evaluate how quickly a developer was working. The concept was that if one developer could code 6 KLOCs per week and another could code 10, the second one was obviously faster and therefore more valuable.
But, unless that KPI is limited to projects that are essentially identical in requirements, complexity, use the same development platform and programming languages, and are in all other ways indistinguishable, it’s of no value at all in comparing two developers. And, even in that unlikely scenario, the fact that one developer is able to successfully accomplish all of the project’s parameters with less lines of code because of their experience or elegance really shouldn’t be held against them.
How to best use KPIs to evaluate developer performance
The only way to leverage the benefits of using established KPIs to evaluate developer performance without succumbing to the potential pitfalls is to develop KPIs for each individual project, and to do so in conjunction with the developer you’ve chosen to work with.
This flies in the face of the common practice of listing out established KPIs (or, what are being labeled as KPIs) in job descriptions and hiring notices, since there’s obviously no opportunity to collaborate with the developer in creating them. For the purpose of hiring a web developer, other more appropriate factors should be considered in lieu of project-specific KPIs.
Collaborating with the developer in establishing project-specific KPIs will allow the client to monitor the metrics that truly matter in a manner that effectively takes each project’s unique requirements into account. It also allows the developer – arguably the more experienced and knowledgeable of the two when it comes to the details of web development process – to provide input that will keep the KPIs both realistic and value-based.
If you’re seeking web development help and need some input on KPIs, contact us to discuss what would work best for your project.
