The CI pipeline takes an hour to run and it’s getting longer every month. There are five slightly different implementations of the same thing in the codebase. The docs for the network module were last updated two major versions ago. The project has a few thousand warnings. “It is what it is.”
The project you work on may not be as bad as this, but there are pockets of persistent inefficiency all around. Larger organizations have more of them simply because there are more cracks between domains of ownership. When you work alone, you’re authorized to make things better by default. When a hundred people and a dozen or more teams share a project, it becomes unclear who can change what (and to what extent). People start looking away: “It’s not what I’m supposed to work on. This will disrupt other people’s work.”
The team needs to be disciplined and conscious of creeping entropy to avoid this. Unchecked, the project naturally becomes a Big Ball of Mud as described by Brian Foote and Joseph Yoder in their 1997 article of the same name:
A BIG BALL OF MUD is haphazardly structured, sprawling, sloppy, duct-tape and bailing wire, spaghetti code jungle. We’ve all seen them. Their code shows unmistakable signs of unregulated growth, and repeated, expedient repair.
Someone on X said just the other day: “Pull requests and code review are a complete waste of time! Why would I work in such a low-trust environment?” Radical (engagement bait) and generally true, however most of us do not have free choice of workplace and project. Sooner or later you may end up working on a Big Ball of Mud, and what are you going to do then?
I find that using just four words, you can start improving the situation (no, they are not “rewrite it in Rust”). When I noticed I was frustrated, I started saying: “We can do better”. What does it mean? It’s a call to remember the ambition and striving for engineering excellence. No one purposefully wants to be a bad software engineer. We all want to write neat and elegant code. When I look at another ream of sloppy code, saying “We can do better” reminds me of this feeling: “Is this really the best we can do as a team?” This naturally leads to the next question: “What small thing can I do right now to make this just a tiny bit better?”
Small changes compounded over time make a big difference. It’s the core idea of the Japanese concept of kaizen or continuous improvement. Looking at a swamp of bad code, you may feel it can only be completely drained and the pit filled with fresh concrete — but for a single person, it’s too much work. Instead, you can do what you can alongside regular work. This undercurrent of improvement gradually clears the water around where you’re working.
Even when a team is not particularly engaged, they never oppose others who take initiative to make improvements. That empowers you to effect good change. Remember small steps? Nobody opposes small clearly beneficial changes. You will find that people actually want change for the better. Who doesn’t? Your efforts will be cheered, and then things really start to turn around — led by your example, people begin bringing and implementing their ideas.
People feel powerless on large poorly managed projects — you can’t improve much alone. Showing that positive change doesn’t have to be large empowers others to make tiny changes and build up from there. Slowly, this creates a net-positive culture and melts tech debt.
What is a tiny change? Adding one line to the project README saying which exact version of supporting software to use. Improving a frequent error message to be more clear. Writing a two-line bash script to automate something people had to do by hand. Sorting a list of five debug options so that the one people most often use is on top. Adding a three-line helper method and replacing 74 ad-hoc implementations across the whole codebase.
All of the ideas above are improvements to the developer experience. What about delivering customer value? It is simple: a better developer experience means developers spend less time being frustrated with their tools and more time working to deliver the best customer experience. All of the project code, if you think about it, is a tool to bring value to customers. Of course, the same approach can — and should — be used for improving user experience.
It is what it is, until we make it better.