We’ve heard the term “technical excellence” being used a lot, both by developers and by business analysts. But like “fashion,” or “honor,” or “groovy,” it’s a word that is hard to nail down—despite the fact that everyone feels like they know what you mean by it.
One might go a long way in their career without worrying about the exact definition of the term. We worry about it, however, because it's right there in the Agile Manifesto as the ninth principle:
“Continuous attention to technical excellence and good design enhances agility.”
So what is technical excellence? Is it something that can be measured and influenced? (And would that be something we really want to do?) And whose job is it to worry about technical excellence? (Is it something we should be worrying about at all?)
The word “excellence” should be a giveaway here. “Excellence” is a term that captures performance, and so it is a matter of both objective measures and subjective values.
Which means that, for us, the meaning of technical excellence is also going to be rooted in the values and approach of the organizations involved. (Or, you could say that it is an expression of those values.) That makes it something of a moving target. The standard of technical excellence in an organization working within an agile mindset is going to look very different from the standard in a large corporation using traditional waterfall methods and management approaches.
In fact, you can see this difference by looking at a “standard” definition of technical excellence (hat tip to Google for the help!) and the way our developers talk about it. First the common definition, this one from a project manager on mmbuildings.com:
“Technical Excellence is the ability to foresee and eliminate an issue before it has the potential to jeopardize safety, schedule, budget, quality, and most importantly, client satisfaction.”
OK, cards on the table—this definition actually came from a construction firm. But it could just as easily apply to software development, or any other business. And it fits the traditional mold. Here, technical excellence is really about mitigating risk, about protecting those things that the firm (and presumably, their clients and vendors) want to protect: Personnel, schedule, budget, and reputation.
We don’t disagree that these are things worth protecting (especially the whole employee safety and client satisfaction parts). But contrast that definition with the way in we talked about technical excellence, here in one of our latest “Raise the Bar” videos:
Here are a few definitional highlights from the session:
Matt House:
It’s attention to detail. It’s craftsmanship. It’s continuing to look at what you’ve built, and also looking forward. It’s knowing that what you’ve built probably isn't good enough right now, but you can see the path forward to building something that's sustainable over time.
Me (Ian Garrison):
I think a key part of technical excellence is knowing what [is required] to maintain quality and craftsmanship, and building that into whatever problem we’re trying to solve...technical excellence ultimately gets you to ask, “Well, what are we solving now? What's the right tool to solve this problem without so much overhead that it slows us down? Where do we find that right balance for all of our practices?” It’s knowing which tools to pull out of our toolbox and how to use them.
John Krewson:
Balance. I think that's huge because there are a lot of really smart ways to protect your software from all of the different ways that it can fail. But the ultimate failure is: nobody uses it. So who cares if it's protected from all the other failures, if nobody is going to use it?
On the other hand...technical excellence is also the difference between what you can build as a hobbyist, and what is “industrial grade” and can be supported, in the long-term, by a group of people that you've probably not met yet because they haven't been hired yet. But we have to go back to balance, though, because they might never work on a bit of code simply because they determine that the feature [in question] is useless.
Notice that, for me and other developers here at Sketch, technical excellence is not a matter of protecting anything. Nor does it involve foreseeing all possible problems—in fact, when it comes to software development, that’s probably impossible anyway.
What comes up more are the following ideas:
We’re not saying that this is the core of the idea. Again, a term like technical excellence is bound to be an expression of values, and so it differs from organization to organization.
With our framework for technical excellence in hand (and knowing that it is an expression of our values), let’s see how we would answer the above tough questions:
Is technical excellence something that can be measured? Yes and no. We acknowledge that most organizations measure it by KPIs such as defect rate, or absence of technical debt. We are proposing that, viewing technical excellence the way we do changes how you measure it.
Technical excellence, in our concept, does provoke a reaction, which means it can be rated—in just the same way as an Olympic judge would rate a diver, or an antiques dealer might evaluate the craftsmanship of a wooden chair.
It’s less clear that you could do this algorithmically, with established KPIs and metrics. In the end, the only metric that matters is whether or not useful software (or whatever product you are working with) has been produced.
Whose job is it to worry about technical excellence? It is first and foremost a concern of the craftsperson. They should always be wondering: How can I make what I’ve created even better? What would make it more useful? More streamlined? More durable? Experience and attention to detail together result in more excellence over time.
But it should also be a concern for anyone who might be working with (or for) a craftsperson to create or market a product. How can they provide the best working environment for that craft to happen? How can they verify that the best products are going out the door? What are the use cases, and is the product actually meeting them? Are the users happy with it?
Is technical excellence something to worry about at all? In this regard, technical excellence is a bit like water: We tend not to worry about it too much until we’re thirsty, and we become obsessive when we’re parched. So when technical excellence is missing, everyone in the organization will feel it. The priority, then, is to create an environment that will capture it and retain it. But when it’s present, it should just be there, in the background. Trying to monkey with it further might do more harm than good.
Food for thought. Meanwhile, why not check out some of the other “raise the bar” episodes on our YouTube channel?
Your blog post content here…