Think Before You Do: KPI in Software Development

What are the Key Performance indicators (KPI) for management to use to measure their Software Engineers? Some would argue that it's simply based on the amount of code they write and why not? It's an easy way to consider throughput. Can't Software Engineering as a discipline be simplified to "Solving problems with Code"?  In my opinion, code throughput is one measure but it shouldn't be the only one.

What does the business actually need?

So let's try to define the business needs as a user story so we can express "what" is expected. As a Business I need the Engineer to solve my customer's problems through Software so that I can: <Ultimately make money>. Choose whatever other way you want to express the "why" part of the statement but in the end it's really about this. Notice that in NO way have we expressed amount of code in this user story we just simply stated "through software".

How does an engineer accomplish this?

If we agree that this is a viable user story for our business then let's concentrate a bit on "how" engineers do this. There are many things to consider when it comes to solving problems as an engineer:

• Are the requirements fully vetted? 
• How does the current framework work?
• Is there a simple way to extend and/or use that framework to solve the customer's problem?
• Do my changes impact the way our software scales/performs?
• Do I need to vet my changes with an architect or even other teams?
• Does a specification need to be written or at least a basic approach?

These are just a few questions that must be answered before an engineer starts coding and it's part of the cost of doing business as a software company. I'm not saying write 'NO' code. I am saying think about it then write what is needed.

The hidden costs of MORE code

Speaking of the cost of doing business and saving money let's consider the hidden costs to having MORE code through a series of opinionated statements.

The more code you have:

• the more engineers a company needs to maintain it.
• the more places bugs can exist.
• the harder it is for a new engineer to learn and contribute.
• the more time it takes to solve problems.
• the more moving parts the engineer has to maintain in their head as they read the code to determine even where to make a change.

Conclusion: We pay our engineers to both think and code. Both provide value to the company. Less code is: easier and more cost effective to maintain. Writing less code actually requires brain power. We have to trust that our engineers have thought through their solutions and have not written code because it's the only KPI to measure them by.

As a suggestion: Try creating research stories/tasks that count (in terms of throughput) as much as coding efforts. Put those into your backlog before fleshing out the actual coding tasks and then iterate. Use the combined "thinking" and "coding" efforts to measure overall effectiveness.

PS: I'm not the first to have the opinion "Less code is better", just search for that phrase and read through other engineer's arguments.