I recently read a good article: The Quiet Crisis Unfolding in Software Development.

It warns the software manager to be wary of high performers. It alludes to a situation where the developer churns out code without regard for maintainability. The issue it highlights is that if you’re evaluating performance through the narrow window of “functionality added”, without delving into the quality of the code people write (as a manager may often do), it’s entirely possible to get false positives for high performance. It’s also an issue of short term vs. long term, both in terms of length of observation and management priorities (which are often extremely focused on the short term).

I have seen two examples of false high performance in the workplace:

• One is a person who churns out a lot of code. In the worse case, it’s buggy but (insidiously) the bugs may show up in other components, making other people waste time on fixing them. In a somewhat better case, the code works but ignores established conventions and/or the developer doesn’t care to propagate the changes to the rest of the code base (e.g. suppose they introduce a superior logging mechanism in their bit of code but they don’t give a toss about replacing it in the rest of the code). Again, these changes fall on the shoulders of other people, bringing their observable performance down. This may look like high performance to the manager for some time, especially because the performance of other people has gone down. The complaints and the realisation that bugs are introduced at a higher rate compared to other people will take time to percolate up to the manager.

• Another case is more interesting. It’s a person who writes a lot of good code, but the code they write is beyond the understanding of the rest of the team. The rest of the team then struggles to use it, and they have to keep going back to the original developer for help. This definitely looks like high performance to the manager (hey, this developer is solving complex problems AND helping teammates!), and maybe even to the developer team. But ultimately, this isn’t a great situation either. Without bringing everybody else to the same skill level, this is a dysfunctional setup.

Of course, viewed from another angle, the issue is really with the manager and not how they measure performance. Adding lots of code along with a mounting technical debt may align perfectly with the (short term) priorities of the manager but brings everybody’s performance down when viewed over the long term.