Is it just me, or have aliens taken over the brains of our managers, convincing them that a number can accurately represent the quality of a product or the value of a developer? Exactly how much data entry, analysis, and forecasting crud must we endure just to placate misguided managers enough to leave us alone so that we can do our jobs? Am I the only one with a deep visceral sense that if we actually were allowed to focus on coding we’d get a lot more done?
Yet the trend is to “measure” more and more of what we create and how we create it and to use these measures to determine the goodness of our products—and of our people. As if disengaging our brains were advantageous. Do you realize how many otherwise intelligent managers could easily second-guess their own best judgment about a person and rely on a “coding success metric” to rate the members of their teams?
Eric Aside I was asked by the Interface editors to write a piece about metrics. I don’t think this is what they had in mind, but deadlines are deadlines and I provided the word count they requested.
Careful what you wish for
The Interface article “Measuring developer productivity” nicely balances information about the various metrics used to measure devs against the weaknesses of using measures at all. Primary among these weaknesses is that metrics are easily “gamed.” Managers will basically get what they ask for. If more lines make the metric better, they’ll get more lines. If fewer check-ins makes the metric better, they’ll get fewer check-ins. Not because the code is better or the developer is better, but because it makes the measure look better.
As long as people believe that they are being judged by a number, they will do whatever is necessary to ensure that the number makes them look good, regardless of the original intent of the measurement system. After all, why go out of your way to do the right thing if it doesn’t improve your standing?
Are all measures useless? Not if they are used to track team and product progress against well-defined and accepted goals—like performance, regression rates, find and fix rates, and days to customer problem resolution. Measures can help drive teams forward and give objective meaning to achievements. However, they never take the place of good judgment.
Eric Aside I’ve since learned a great deal more about constructive metrics. You want them to measure desirable outcomes—ideally, team-based desirable outcomes. Outcomes focus on what instead of how, which provides freedom to improve. Team metrics drive shared purpose instead of competitive dysfunction. “Lines of code” is rarely a desirable outcome. However, “shortening the time to produce a high-quality feature from start to finish” is a desirable outcome, and it depends on the whole team, not an individual. I dive deeply into this topic in How do you measure yourself?
Rather than attempting to place a number on individual developer productivity, managers should be answering the question, “What makes a good developer?” If it were as simple as assigning a number, theorem-proving machines would have replaced all of us a long time ago.
Playing a role
The key to measuring the value of developers is to think about development teams, not just individuals. Different people bring different strengths to a team. Consider the role that developers play on your team when judging their contributions. The best developers to have are not always the ones who code the best or fastest.
You don’t want a team full of architects any more than you want a team full of leads or a team full of code grinders. Each team needs a balance of talents to be most effective and productive.
The makings of a great dev
But enough skirting around the issue of “measuring a dev.” Here are what I consider to be the defining characteristics of great developers:
- They know what they are doing. When you ask great developers why any given line or variable is there, they have a reason. Sometimes the reason isn’t great (“I took that code from another place, and it used that construct”). But the reason is never, “Aw, I don’t know, it seems to work.”
- They don’t believe in magic. This is a corollary to knowing what they are doing. Great developers don’t feel comfortable with black-box APIs, components, or algorithms. They need to know how the code works so they don’t get burned by a false assumption or “leaky” abstraction (like a string class with simple concatenation that hides allocation failures or O(n2) time to execute).
Eric Aside Kudos to one of my favorite “Joel on Software” columns, “The Law of Leaky Abstractions,” which you can find at http://www.joelonsoftware.com/articles/LeakyAbstractions.htm.
- They understand their customers and business. I talk about this in detail in Life isn’t fair—The review curve. Great developers know what really matters, and they can prioritize and make proper tradeoffs.
- They put customers and the team before themselves. No task is below a great dev; no customer is unimportant.
- They have uncompromising morals and ethics. Although individual preferences may vary, great devs care about how they accomplish their work and how they act toward others. Whether in the algorithms they choose or the e-mail they write, they set the bar high for themselves and will not waver from their core values.
- They have excellent people and communication skills. Although not many developers would make good game show hosts, great developers work well with others, respect others, and communicate clearly, effectively, and appropriately. They don’t choose to bully or intimidate (although they could), but instead collaborate. (More on this in My way or the highway—Negotiation.)
- They have a wide, supportive network. Great devs recognize greatness in others and are drawn to each other. They quickly develop a network of contacts that support one another and that allows them to be far more effective than any single individual. (For more on building your personal network, read Get yourself connected.)
Other specific aspects of the general characteristics I’ve listed include focusing on quality, mentoring others, and displaying exceptional design skills.
None of these characteristics that define a great developer can be simply measured.
You be the judge
When push comes to shove, you as a manager must judge your team as fairly as you can in the roles that each member plays. Having examples from other teams helps give you perspective on your own developers; this is why calibration meetings are so valuable, instructive, and worth the agony.
But remember that no calibration or rating can hope to represent an individual. People are far too complex, and even the most objective metrics are distorted by perspective. Knowing and valuing people as real human beings is the key to unlocking their full potential.
Be First to Comment