I don't like the concept of "bad code". I thought: "Let's ask people what they consider to be bad code". I got some responses. (It's hard to say this is a representative sample of opinions, but better than nothing.)
Talking to people in comments of the first post helped me to crystallize my thoughts on what is bothering me in this idea.
What is wrong with "bad code" notion?
"Bad code" notion:
- is ambiguous. People have different opinions on what that suppose to mean
- is "blamatory". I guess this is not a word, but you get the idea - when you blame somebody
- is confusing (not descriptive). When somebody says: "This is a bad code", the immediate reaction is: "Can you explain why?"
- is negative. It feels like bad code is taboo and you shall never write it even though there can be valid reasons to do so
- is relative. Most often answer to the question (what is bad code?) was lack of readability. Readability depends on the reader e.g. it is relative
Let's discuss case by case.
Ambiguous
ambiguous - capable of being understood in two or more possible senses or ways
First of all there is no single definition of what is bad code. Every time you mention "bad code" you must provide the definition, otherwise, people can have a different idea of what you are talking.
Ambiguous terms are hard to use in conversations. You need to spend some time to remove confusion.
For example, people considered following to be the definition of bad code:
- Not following specification
- Hard to read, hard to modify, hard to delete
- Poor performance
- Hard to test
Blamatory
Blamatory - to be in the act of blaming somebody.
When you declare that code is a bad person who wrote it will feel bad. This is not a way to have a constructive conversation.
There can be reasons why the code is not satisfactory:
- there was pressure, like lack of time, or pressure from management
- the person was new to the subject (and maybe not anymore)
- the person was stressed (maybe not work-related issues)
A better approach would be: "Hey, I have troubles working with this code. Can you explain why this is done this way?" or "Do you want to work together to improve this code?" or "Can we create a ticket for tech debt and describe how we can improve this ticket?".
Confusing
Сonfusing - to fail to differentiate from an often similar or related other.
When you declare that code is bad, the author would ask why. And the answer can be because it is hard to read or it is hard to change etc. Why wouldn't you say in the first place?
Instead of "code is bad" you can say "I have troubles reading the code". The second phrase feels different than the first one. First is blaming, second is asking for help. And helping people is in our nature (this is a mechanism created by evolution, to help societies survive. Read about "prisoners dilemma" if you want to know more). Asking for help works much more effective than blaming.
When the request is more precise like "I have troubles reading the code", it can remove confusion. For example, in this case, we can assume two cases, the code is written the way it is hard to read for the whole team and we need to change it, or reader sees this pattern for the first time than we need to educate the reader.
Negative
Negative - lacking positive qualities.
It is negative and it feels like it lacks all positive quality. In many companies, the IT department is busy with the main business and other departments lack IT attention, for example, tech. support or marketing or BI. As a result, they end up writing software for their need themselves. They simply struggle to do their work and to make it easier they want to automate it. Imagine they wrote something in some arcane language or Excel.
Now some IT person shows up to check what they did. Would this IT person dare to call this code bad? I mean it will be probably not what developer expect, and probably not version controlled. But it helps people do their job, and you (developer) wasn't there to help.
I wouldn't dare to call it bad. If I want to improve the situation I would teach them some basic code hygiene, like version control, writing readme, making reproducible build.
The negativity in the words creates taboo like in some religions you must feel bad about some things. The same way you must feel bad about writing bad code.
You don't have to. Hereby I grant you right to write the bad code, but be aware of the consequences. With great power comes great responsibility.
Examples of valid reasons to write "bad code":
- You write some prototype. You use code to test some hypothesis, for example about UX. Hypothesis check may fail and you can throw out all the code
- You want to trade quality for time. Obviously, you will get tech debt (which can kill a project), but maybe you need to show something quickly to get financial support and you will get time later to pay the tech debt
- you don't know how to write good code and you spent quite some time trying to improve the existing one. In this case, I write down what I don't like about the code and commit it as is. Later (in a day or a week or a month) I come up with the idea and change code pretty fast. Sometimes you need to give time to your brain
Relative
Relative - not absolute or independent.
Most mentioned definition of bad code was poor readability. Readability depends on the reader, which makes this notion relative.
For example, there is a team of OOP developers, and person which prefers FP joins the team, and write new code FP style. For the rest of the team, it will be hard to read FP code, because they used to OOP-style, for them this is "bad code". But this doesn't make it universally bad code in FP team that code could be perceived as good code.
In this sense notion of bad code is relative, it can change from team to team. It can depend on time - maybe this code worked well previously, but now hardware changed or requirements changed.
Good code
I'm opposed to the notion of "bad code", because of it's negativeness and poor communication properties, but I'm not opposed to the idea of "good practices" (I prefer good over best), like readability, testability, etc. I guess this is subject for the next article.
PS
This article is food for thought. I'm not saying you all should follow this as a mantra, just an alternative opinion for you.
Photo by Jonathan Daniels on Unsplash
Top comments (2)
We should not conflate saying the code is bad with saying the developer is bad. A dev might have to rush out a ux prototype. We can acknowledge it is possible a developer has to make compromises and maybe did a great job that resulted in less than ideal code. There is no contradiction there. In a blame free postmortem culture you acknowledge that people don't cause bad outcomes it is the situation. In the case of tactical code used in a prototype that tested a UX hypothesis it could be a good outcome. If so no postmortem.
Eventually everyone encounters a ”throw away prototype” that makes it onto production and causes dismay. At that point you won't say ”this is okay code that has me working late because the developer made necessary tradeoffs” you will say ”this code is bad”. Keep coding long enough and you will hit a situation where you were the author of the code. I don't think of myself as a bad person when I encounter that situation. I simply wish i had written better code. A mentor of mine told me he doesn't write throwaway code as he never had the time to learn how to do that as he is too busy every day trying to figure out how to write good code. I decided to be like him and when someone pressures me to meet a deadline I maybe put some more hours in but I never ship code I don’t feel a sense of pride about.
A huge amount of effort is expended by the industry and by developers trying to write better code. To argue that there is no such thing as bad code implies that there is no such thing as good code. That implies that all the effort that we individually and collectively expense to improve how we code or improve the code base before us is wasted effort. It isn't.
In my experience on large codebases with big teams the majority of devs believe that there is such a thing as bad code that they encounter with some frequency. It is contextual and relative and hard to measure. It has been argued that because it is contextual or relative and hard to define it doesn't exist. This isn't a compelling argument.
There will be some set of criteria or metrics, even subjective, that can rate the success of a piece of software. For my hobby projects it could be stars on my GitHub repo. At the office it could be billed hours to ship a story and maintain it over one year. We can perform a thought experiment and imagine that someone decided to sabotage the hobby or work project. That person slips in code with hidden bugs designed to be as hard as possible to fix. They deliver a masterpiece of deception. People don't recognize it as harmful code. It passes the reviews and appears to be like the rest of the software by any qualitative or subjective measure. The early bugs are apparently fixed but more issues are encountered by users due to the way fixes interact with the original code. To the saboteur the deceptive code is great code. It maximises their preferred outcome of bugs, lost revenue and developer misery. To everyone else it is bad code.
That thought experiment demonstrates that even if it is relative, hard to define, and hard to distinguish, bad code exists. This is a fictional example of someone deliberately trying to write bad code. Yet many devs will have encountered such deceptive and tricky to fix code where the author was just trying to do their job.
I don't say this is a "bad code". I say it is hard to work with this code (for me). And the next thing I try to figure out why is it hard, is it bad abstraction, is it due to changed requirements, is it misleading naming (maybe I interpret code differently than author), maybe I don't know something, maybe I have poor understanding of business model, maybe there are some business constraints, etc.
Think from this side: "bad code" is possibly a false claim (there is always a chance, that this isn't bad code, but you don't know something). Where is "I have troubles working with this code" is always true claim.
To me this is not bad code, this is malicious code.