Sometimes software developers (or a worker in a different discipline) work on completing a certain task and move on, without considering if the previous code they’re modifying could be improved. Or they don’t consider if the code they’re adding carries flawed practices that can be updated.
After completing their assignment, they move on the next task, where they’ll surely repeat this pattern. They don’t stop to make a real impact in the product, to make it considerably better than what it is.
What are the reasons for this? It’s easy to blame it as laziness and lack of interest. But is there something else behind it?
Of course, sometimes the code is already good enough, so there’s no need for an overhaul. At other times, we’re in the middle of a sprint and shipping is a priority. These are real situations and we won’t focus on that. Instead, we’ll focus on the situations where there’s room and need for an overhaul.
If you care about it, challenge it
Automattic—the company behind WordPress.com, Jetpack, and WooCommerce, among other products to build a site—has a creed, and one of its sentences is “I won’t just work on things that are assigned to me”. I’m going to pair this phrase with something that Automattic’s CEO Matt Mullenweg said internally to automatticians “if you really care about something, you’re expected to challenge it”.
This strong mindset is a stark contrast to the behavior of patching something and move on. It asks you to improve the entire product, as opposed to simply complete your task. It asks you to stop and consider: “is this the best way to do it? How can I improve it?”
But there’s resistance.
That force that Steven Pressfield calls out in his book Do the Work, that invisible force inside us that he claims acts against human endeavors:
- developers are tempted to blame the previous developer: “it was done like this before. I know it’s not efficient, that is incorrect, but what can I do?”
- they’re are tempted to blame their current timeline: “we’re doing things fast. We don’t have time for that.”
- they’re even tempted to blame their future timeline: “that technology is good and will probably improve our workflow. I’m not sure if we’ll have the time to learn it though.”
So what’s behind it?
It’s easy to think that these developers are lazy, that they resist change. Maybe that’s not all of it. You can also note that these developers feel powerless:
- they don’t feel empowered to be an agent of change
- they are overwhelmed by the time constraints
- they even feel insecure about the future
When a company falls into organizational chaos, the last two show up really quickly. Time is never enough, technical debt keeps piling up, developers are burnt out, product direction is erratic trying to cope with different management requirements.
At this point, the first one will definitely appear: burnt developers feel powerless. They don’t feel like they’ve the strength to change anything. Their managers only recognize the immediate bugs to fix but not what is leading to them. Developers are barely coping with the day to day requirements, so it’s impossible to think in refactoring a codebase even if that’s the source of all the issues.
In other cases, resistance come from the individual developer, either by insecurity, lack of knowledge, narcissism, passivity, and so on. Sometimes, in very rare cases, they just don’t care. The job simply means a monthly salary and they’re motivated by the money, not the impact in the world.
There’s however, a greater force inside each individual that can effectively counter the resistance: their commitment to the product, the company, and most importantly, to the customers they’re catering.
Like Susan Fowler says in her book “Why Motivating People Doesn’t Work…and What Does“: people are always motivated. The question is not if, but why they’re motivated. It’s up to the managers to discover this motivation and channel that energy.
Even if they have this inner force, change is really hard for individuals. Managers have to be there, leading by example, helping developers to improve. Here’s a few ideas to implement:
- Start by identifying and quantifying it. What are the areas where it’s happening? Are there some correlations in the areas and this behavior? Is some manager covering up or justifying this? That will give you an idea of how complex the issue is, and will allow you to plan how to approach it.
- Don’t call it out. People don’t react well, they will get defensive and try to justify it. Even worse, some people have to continue doing what they’ve been doing to prove that they weren’t wrong.
- Instead, lead by example and inspire. Are you a development manager? You can get hands on and improve something. But ask first. One good quality of leaders is that they trust their followers, and will ask for advice. That ends in a cycle of mutual trust. Improving some critical but forgotten feature will surely make a noticeable impact and developers will be inspired to follow.
- Make developers own stuff. Make them responsible for areas for a long period of time. This will grow confidence in them and the responsibility will eventually drive them to start polishing things as much as possible. They will stop blaming the previous developer after a while. And if they continue doing it, ask them to improve it.
- Show developers what’s in it for them. From small things like recognition across the company for updating a really outdated portion of code, to the benefits of faster development and a more relaxed work environment with less stressful emergencies to fix bugs. Positive reinforcement and clear expectations of the benefits that will be brought by a certain new approach will work wonders.
- Plan and define the technology to modify or introduce. When projects don’t have a defined scope regarding technology, things start going sideways creating uncertainty. A well defined plan gives certainty, stability, peace of mind. And if something unexpected comes out during the development, the developer owning it should notify a manager as soon as possible, rather than at the end of the project.
- Oversee the development cycle. When someone creates a pull request in a Git repository, it’s the perfect moment to review the code and assess if it’s just a matter of completing a task because the code is already in a good shape or it’s a chance to make a meaningful impact.
- Finally, continuously review the company practices and processes. Everything and anything must be subject to review and change if new solutions and approaches to improve things and make them more efficient are found.
I’ll finish this by mentioning the Acumen manifesto, which is pretty great, and a couple of its lines can be well applied to this issue and overcoming it:
It thrives on moral imagination: the humility to see the world as it is, and the audacity to imagine the world as it could be.
The codebase might be what it is now, and it might be flawed, but developers can change it, they can make it better. They should feel themselves both empowered to do it and with the responsibility to do it.
It’s leadership that rejects complacency, breaks through bureaucracy, and challenges corruption. Doing what’s right, not what’s easy.
It’s an inspiring leadership that will help changing this behavior in your organization. It’s accepting the individuals with its flaws and getting rid of them, like a father cleaning the mud in his son. Outcasting complacency, doing whatever it takes to make a lasting improvement in the company processes and the product.