On a lighter note, bad code generates ample employment opportunities.
- One of the many good developers needs to fix the bad code.
- One or two senior developers need to review the code and ensure it does not become bad again.
- The bad programmers (the stars who wrote the jumbled mess of logic) may need to be consulted from time to time to make some sense out of the gibberish.
That said, we all have been there. We tirelessly burn the midnight candle, trying to close a particularly painful bug and we come across a code section; the root cause of the problem. As you try to make sense of the spaghetti — an impossible-to-read, jumbled mess of logic with zero comments for the umpteenth time, you curse under your breath.
“Who the h#%$ wrote this?”
“Who could be so foolish?”
“How can anyone write code with such incoherence and blasphemy?”
This is the wrong way to begin. After all, all of us, at some of the time would have written bad code. Every other developer on this planet creates security flaws, misaligns UI elements, and more at least once in his life. It is not that he is a bad developer. He is just human.
And the way you respond to bad code has a lot to do with your future roadmap as a good developer. Good developers leave aside any personal or tribal vendettas and get into a deeper understanding of the code rather than pouring their wrath on the unfortunate developer who wrote the code.
Good developers avoid subjectivity and give constructive, objective criticism to bad code so that it does not repeat again. They convert it into a learning and sharing opportunity so that everyone benefits in the process.
And here are some ways in which good developers deal with bad code.
Identify the problem.
Duke Ellington has rightly said.
“A problem is a chance for you to do your best.”
Approach the problem with curiosity and empathy for the person who wrote it. The issue with code, in general, is that there are multiple ways to write it and no way is the best way. So before you evaluate the code, try to find out the reasoning behind the code. Put yourself in the other developer’s shoes and identify the problem statement.
Too often, programmers are stubborn. They do not like to be told of their mistakes. The correct way is to empathize with the person and find out what makes them write such rampant GOTOs, such deeply nested switch statements, and such obtuse naming in the first place. You will soon get the reasons.
“I had to complete the code in 1 hour”
“There was no API available”
“My domain knowledge is limited”
And so on….
By identifying the problem, you are not only seeing the issue from their point of view but you might also come up with a specific line of attack to rectify the code instead of hitting in the dark.
Ask prudent questions.
Francis Bacon has rightly said.
“A prudent question is one-half of wisdom.”
Once you have established the problem with the code, the next step is to sit with your colleague and ask deeper questions. The key here is prudence. Your best bet is to ensure that the question-answer session does not degenerate into a brutal Spanish Inquisition.
For the history buffs, the Spanish Inquisition was started by Ferdinand II of Aragon and Isabella I of Castile, with the assistance of Torquemada. During the Spanish Inquisition, many people were burnt in front of crowds in the streets. In practice, the Spanish Inquisition served to consolidate power in the monarchy of the newly unified Spanish kingdom, but it achieved that end through infamously brutal methods.
By asking logical questions, you are not only consolidating your understanding of the problem, but you are also allowing the other developer to self-identify his errors and teach him the right queries, he needs to ask himself every day before writing code. By asking questions, you are also showing that you are open to his point of view. When your colleague feels respected, they are less likely to get defensive.
And once you get to the error and the reasoning, it is your responsibility to spread the wise words across the team so that no one writes crappy code again.
Curb your rewrite instinct.
Anthony J. D’Angelo hits the nail on the head when he says.
“Don’t reinvent the wheel, just realign it.”
Writing high-quality code takes more time upfront than poorly written code. Sometimes, it can make business sense to “get something out the door” faster. Kimber Lockhart, in a presentation as part of a hack summit says that one of the biggest mistakes developers do to address bad code is to rewrite the code again. Rewriting code is not an answer to bad code most of the time. There are a lot of questions to be asked before taking this step.
Is the rewritten code going to be better than the old version?
Is the cost-benefit analysis worth the effort?
Is all the old code really bad or can we reuse a lot of it?
And so on….
She proposes a 3-step approach to deal with bad code.
Prioritize the code. What needs to be fixed first? Can we live with other portions of the code?
Encapsulate the bad code. Keeping the old code running but keeping it separate from new code by wrapping it in a module will mean no one else can add to it except to fix it. The old code can still be called upon, but encapsulating it keeps the bad code from spreading.
Deprecate the bad code. Flag the bad code explicitly so that no one copies the bad code and compounds the problem further. Lockhart suggests deleting bad code, but doing so with caution. Investing a few hours a week to create an automated system in order to identify code to be deleted would be a good way for a long time cleaning of the system.
The key is to use the best from the worst and eliminate the worst in a slow and steady manner. Not all, bad code is because of technical debt and if there are good areas, we should be smart enough to reuse and adapt.
Lastly, be humble.
Zig Zigler has rightly said.
“Humility will open more doors than arrogance ever will.”
Pride is the downfall of many a tragic hero.
Mr. Darcy from Jane Austen’s famous book “Pride and Prejudice“ had to let go of his pride before he could earn Elizabeth Bennet’s love. Dante listed it as one of the seven deadly sins. And as the famous (and often misquoted) verse from Proverbs cautions us, it “goeth before destruction and a haughty spirit before a fall”.
There is no question about it. The thing that defines truly being humble is a quiet understanding that you are good at what you do, but you do not expect others to praise you excessively.
So if you have fixed the code, don’t let your ego play you through. Don’t spam the entire team with emails. Don’t scream over the rooftops at every opportunity. You are also not infallible. You can also end up in the same shoes and when that happens, you need everybody’s help and support. Never forget that.
Of course, that does not mean, you should not educate others and share your pearls of wisdom. You need to promote a supportive environment with your colleagues and improve the overall output of your team. However, there is a blurred line between sharing knowledge and patronizing knowledge and you should ensure you never cross that line for the well-being of everybody including yourself.
So in short, you approach bad code with an open mind, you learn, you improve and then you educate others to improve.
As Roy T. Bennett has rightly said.
“Make improvements, not excuses. Seek respect, not attention.”