Decreasing team performance
A good way to look at bad code is code lacking the technical practices that help other developers understand what it is doing.
When you’re coding solo, it doesn’t matter so much. Bad code will just slow you down and feel a little demoralizing at times. It does not affect anybody else. However, most professionals code in development teams, which is a whole different ball game. Bad code really slows a team down.
The following two studies are interesting as far as this is concerned:
- https://dl.acm.org/doi/abs/10.1145/3194164.3194178
- https://www.sciencedirect.com/science/article/abs/pii/S0164121219301335
The first study shows that developers waste up to 23% of their time on bad code. The second study shows that in 25% of cases of working with bad code, developers are forced to increase the amount of bad code still further. In these two studies, the term technical debt is used, rather than referring to bad code. There is a difference in intention between the two terms. Technical debt is code that is shipped with known technical deficiencies in order to meet a deadline. It is tracked and managed with the intention that it will later be replaced. Bad code might have the same defects, but it lacks the redeeming quality of intentionality.
It is all too easy to check in code that has been easy to write but will be hard to read. When I do that, I have effectively placed a tax on the team. The next developer to pull my changes will have to figure out what on earth they need to do and my bad code will have made that much harder.
We’ve all been there. We start a piece of work, download the latest code, and then just stare at our screens for ages. We see variable names that make no sense, mixed up with tangled code that really does not explain itself very well at all. It’s frustrating for us personally, but it has a real cost in a programming business. Every minute we spend not understanding code is a minute where money is being spent on us achieving nothing. It’s not what we dreamed of when we signed up to be a developer.
Bad code disrupts every future developer who has to read the code, even us, the original authors. We forget what we previously meant. Bad code means more time spent by developers fixing mistakes, instead of adding value. It means more time is lost on fixing bugs in production that should have been easily preventable.
Worse still, this problem compounds. It is like interest on a bank loan. If we leave bad code in place, the next feature will involve adding workarounds for the bad code. You may see extra conditionals appear, giving the code yet more execution paths and creating more places for bugs to hide. Future features build on top of the original bad code and all of its workarounds. It creates code where most of what we read is simply working around what never worked well in the first place.
Code of this kind drains the motivation out of developers. The team starts spending more time working around problems than they spend adding value to the code. None of this is fun for the typical developer. It’s not fun for anybody on the team.
Project managers lose track of the project status. Stakeholders lose confidence in the team’s ability to deliver. Costs overrun. Deadlines slip. Features get quietly cut, just to claw back a little slack in the schedule. Onboarding new developers becomes painful, to the point of awkwardness, whenever they see the awful code.
Bad code leaves the whole team unable to perform to the level they are capable of. This, in turn, does not make for a happy development team. Beyond unhappy developers, it also negatively impacts business outcomes. Let’s understand those consequences.
