What’s Slowing Your Developers Down?
High productivity in development boils down to trusting the code. Trust in this context means not having to read every line of code because it’s clear what that code represents and how developers can use it. However, they can’t trust the codebase because they can’t trust the names that represent those chunks of code. The names are vague, incorrect, skip information, and worst of all, inconsistent. Therefore developers feel a very legitimate duty to open every chunk of code and read it carefully before acting on it in any way.
The cost of this much reading? Over half your story development.

Any analytical knowledge worker would likely respond by making the naming consistent and correct, right?
Naming code is much harder than it would appear to be.
Why Naming is Hard
As developers care deeply about quality code, they try to come up with great names when they create them. They want to name it right the first time. This is hard and rarely works well.
The reality is that the process of naming boils down to design thinking. Here are the things you are typically trying to do all at once while naming:
- Deciding the things the code should do
- Deciding which things go together
- Deciding which abstractions best represent those clusters
- Picking a name that clarifies the intent
- Picking a name that distinguishes from all the other similar intents
- Describing the side effects of the code
- Keeping your name under 15 characters
This is why naming is hard. Our brains can’t juggle seven cognitively complicated tasks at once. After brain overload, most of us give up and settle for a crappy name.
The Big Picture
Is naming really that big of a problem?
As technical waste is anything that causes delays or rework, anything that makes code take longer to read is wasteful. Bad naming not only introduces time spent reading the code (delays) but misleads the developer, introducing errors that the developer has to slow down, even more, to prevent (rework).
Source of Technical Waste
Developers are good at reading complex code, and any of them would tell you it was their job to update code. So shouldn’t the definition of technical waste be something about the cost and risk of changing code?
Absolutely. And…this is about the cost and risk of changing code.
Before a developer can change the code, they need to thoroughly understand exactly what it is doing and why. Any mistakes or gaps in that understanding will result in bugs. Thus they spend a lot of time making sure that their understanding is correct.
As you can see with the pie chart, the largest single thing developers spend time doing is reading code.
- More than design.
- More than writing code.
- More than scanning.
- And yes. Even more than meetings (well, probably).
According to an analysis from Eclipse data, programmers spend around 60–70% of their entire programming time reading code. So if we want to be more efficient, we need to improve our ability to read code.
Source of Bugs
Bugs are not random. Developers encounter misleading code hundreds of times each day, each with the possibility of introducing a bug. They catch most of them, but the small number that gets past results in about 2 bugs per developer per day. Given that developers are already so good at catching potential mistakes, the leverage point is to reduce risk: present them with fewer opportunities to misunderstand the code.
Looking at when bugs get written, the risk factors that make code easy to misunderstand are:
- methods are long or deeply nested (high cyclomatic complexity),
- code does multiple things,
- concepts are spread around,
- there are side effects.
However, the #1 CAUSE OF BUGS is poor naming.
Why Bad Names are Risky
Bad names are risky because bugs happen when our mental model doesn’t match the code’s actual behavior. And the only place to record a mental model and share it between developers (or to myself in the future) is in the names of things.
Misleading names transmit errors and set up some developer to write a bug.
Why Long is Risky
Neuroscience is helping us better understand how our brain works, including memory. Of the two types of memory, short-term and long-term, active thinking relies heavily on short-term memory. Knowledge work, being mostly deep processing, heavily taxes our short term memory, or working memory, to the fullest extent.
Developers especially fall victim to working memory fatigue and inevitable errors because they are trying to juggle 7 different concerns while also remembering over a dozen different facts about the piece of code they are editing. When common lore says that we can hold up to seven items in our working memory, the reality is that it’s more of a range of 4–7 things and those things are very simple (like a single digit or word). Let’s not forget that it lasts 30 seconds if you’re lucky.
Struggling to read code and name things isn’t about intelligence. It’s about how our brain works.
Thus, it comes as no surprise that productivity plummets and errors mount because the developer is sitting there desperately trying to juggle complex things, losing them, and then starting over. Repeat this cycle enough times and decision fatigue results in a poor name.
The Bottom Line
Given that our definition here for technical waste is code that is difficult, expensive, or risky to change, then the root cause of that is code that is hard to scan. And what makes code easy to scan? Good names.
As such, it is with no exaggeration that we place such a high value on naming practices. Names are the place we communicate our insights and intentions to other humans, and it is with other humans that we must work effectively to produce quality code.
The Annoyingly Simple Solution
Rather than the developer overloading the brain with multiple things at once that are needed for a good name, a name can be iteratively developed as a process. Specifically, a process that is understood by other colleagues so that looking a name instantly tells a developer where that chunk of code is in the naming process.
A clear naming process allows then for the developer to follow the simple steps of:
- Having one insight at a time,
- Writing the insight into a name, and
- Repeating until the name is good enough for today’s needs.
The remaining challenge is to learn how to make each kind of naming shift. Every stage of the naming process requires knowing 5 things:
- where to look for insights,
- what kinds of insights to glean,
- how to write them down in a name,
- how to use tools to do this at speed, and
- how to know when you are done.
We have extracted this into the Naming as a Process blog series that breaks down each stage of the naming process that is designed to be easy to learn and pay off with advantages from the start.

So What Can I Do?
As a developer, we encourage you to read the free blog series and talk to your manager for upgrading to the self-directed or coached version to help your team apply it systemically.
As a scrummaster or manager, we encourage you to share the free blog series with the team and see if they feel an upgrade to the self-directed or coached version to help them apply it systemically.
As a leader of multiple teams, we encourage you to consider your overall technical waste and contact us to help you look for systematic solutions across your teams.
