This is some humble advice on how I believe people should deal with bad code.
It’s not technical advice. Actually it’s not really advice. It’s just stuff I’ve
been thinking of lately.
Typically, the first thing a person does when encountering bad code is determining
who they should blame.
Immediately it becomes a personal or tribal vendetta.
“Who could be so foolish?”
“Who is responsible for exposing my brain to such incoherence and blasphemy?”
“Who insults the house of <Insert Team Name>!?”
This is wrong. This should not be the first step. A deeper understanding of the code
is necessary before we identify the poor soul who should suffer your wrath.
Understand the code
Too often a programmer is sure. People generally are quite stubborn, but I find programmers
to be more-so. Programmers mostly deal in absolutes so I guess such confidence is understandable.
Approach the code with curiosity and a yearning to understand. Empathy for the person
who wrote the code would help too. Imagine yourself in their shoes. They may not be
anything like you. They probably care about different things too. They probably don’t have
the same streak of what you call perfectionism. Their capacity for caring may be directed
somewhere other than the whitespace that nestles their parentheses or the seemingly incoherent
naming of their variables. Maybe they have a life.
Without empathy you are not going to understand the code, nor how it came about.
You will simply sit there vocally festering in your self-appointed superiority.
Really understand the code
Do you want to understand why there are such rampant GOTOs, such deeply nested switch statements,
such obtuse naming, such ugly spacing?
It’s dead easy to understand. Just imagine that the code is yours and that you’re
trying to rationalise your own stupidity. Eventually your mind will fathom sensible
defenses: “I was being rushed”, “I didn’t understand the API”, “I didn’t have sufficient overview of the domain” …
Before you know it you’ll have a battery of excuses, and quite a few of them will probably
touch on the truth. You could have written code this bad. It’s not beneath you.
Question the approach, form an inquiry
As if you were a biologist discovering a new species that had evolved through millenia,
without a watchful eye nor guiding hand. Such a creature begs questions. Such a creature
begs inquiry. Of course, with code, you can just ask the author what their intentions were,
and this is probably what you should do.
Yes, it’s crazy, but true. You can approach the author and ask them. I must warn you though:
this may force you to take a slice of humble pie.
But what if there is no good reason. What if it is, in fact, laziness, or ignorance, or worse,
malice?
Educate
Yep, I’m afraid so. Now that you’ve discovered the error it falls on you to spread
your wise words so that nobody may befall such crappy code again.
Don’t let your ego play you though. Don’t email the entire team. Don’t shout from the
rooftop. Don’t write another blog post. Your biggest mistake is believing that:
- People don’t already know the pearl of wisdom you’re about to share
- People will sit there are willfully accept your patronising tone
And if you have to email everyone. If you have to shout from the rooftops. If you
must write a blog post about a topic that annoys you so, please remember
to inject parody and hints of self-deprecation so as to to disguise your ego’s intent.
If you were to write an article you should title it genuinely though, so as to entice
the stubborn programmer to read your post… something like “how to deal with bad code” would work well.
Seriously, you’re crap too
Yep, sorry. You’re crap at many things. Yeh, yeh, you’re good at some stuff, but you’re pretty
crap at everything else. Don’t blame others for not being as great
as you think you are. The truth will hurt in the end. That you are in-fact the same blubbery
mamallian mass as every other programmer,.. as every other person.
Now for some more delicious humble pie…
Thanks for reading! Please share your thoughts with me on Twitter. Have a great day!
There’s no excuse for ugly spacing!
I don’t think blaming is the first response though. I think maniacally fixing it is.
“Always code as if the person who ends up maintaining your code is a violent psychopath who knows where you live”
Got that from here:
http://c2.com/cgi/wiki?CodeForTheMaintainer
Also the article on Bad Code is worth a read too:
http://c2.com/cgi/wiki?BadCode
@David, it would be great if we didn’t have to worry about the psychopath. It’s like telling children to behave otherwise they’ll go to hell and get coal in their stocking. It works, more or less, but it kinda sucks.
I love this article. I agree, as humans we’re all prone to making the same types of mistakes. Perseverance and understanding is the key to success. Blaming people causes problems, but does not fix them. Understanding does.
I’d love for someone to come along, rant about, criticize and rewrite the code I did on my last project. I can’t imagine the wrath that my absolutely ridiculous variables and redundant functions would cause.
I’d learn, the Teacher would satisfy his urge to cleanse the earth of such horrors, and the client would get his project improved for free.
I’m willing to endure patronizing tone, but too often the Teacher doesn’t impart wisdom, just a smug sense of superiority.
And at least my spacing is nice.
Very good article James. Tribal vendeta makes me smile. This is definitely going to next issue of Weekly Digest.
@paul – the problem is not when the other person realize that he wrote ‘bad’ code, but when he strongly believes, despite all arguments, that his code is ok. Patterns and principles, even when accepted by many, are not universal, and many people have different opinions on what makes ‘good’ code.
I think the worst case is when you look at some old code, rant about how it was implemented, and then suddenly realise that it was you that wrote it!
… and sometimes the original programmer was a lazy git who didn’t give a rat’s ass about his coworkers and the great steaming pile he was going to leave them. I’ve spent the last six months rewriting a major part of our application because I thought a coworker didn’t need adult supervision. I was wrong.
Lets face it, how many people haven’t opened up some code and said “Who the hell wrote this dross?” only to find out it was them a few months/years ago.
Code is in the now; it’s hard to understand the context that the original code was written in; perhaps it was perfect in every way until a non understanding manager came along and said, “We’ve got a great new feature that needs adding in now!” and the bolt ons and fudges began.
I just refactored a chunk of nasty code that I wrote early last year, in a rush (i.e. insert excuse #1), and then came here and read this. Spot on! Something about stones and glass houses, or motes in eyes.
cheers!
Nice article. Empathy is the correct word. The programming is not a problem. The problem is in the people. Problem is in interpersonal communication. For many years :-). Empathy – a different perspective on the matter. Who knows how to see things from a different perspective – he is advanced. And it all starts with the customer. The customer is not stupid nonprogrammers. Nor colleague is not just worse programmer. Understanding and cooperation is more beautiful than narcissistic monologue, which is understandable only to the author himself 😉 Two people are like the two languages. And empathy is crosscompiler … Source code is not only communication with the computer, but foremost among humans. Today most of you do not write code that is separated from the rest of the world. Every man (and programmer as well) is something good and something bad. Not enough to understand a colleague, it is necessary to understand themselves as well 😉
I once ran across a single Java method containing over 32K lines of code in an SOA tool. The coders didn’t realise they could create alternate methods: that was just the way they had always used this tool. Nor did they realise they could write their own package and put it in a jarfile.
I don’t buy anything in your Educate paragraph. I educate by example. Nor do I buy the Seriously, You’re Crap Too. If I find old code of mine I don’t like, that’s because I’m a better coder now than I was when I wrote it.
Now here’s what I tell coders who find code they don’t like. People don’t write ugly code on purpose. Ugliness is what happens when ugly compromise is forced on people: in any discipline. Format it the way you like, comment it, and write a test fixture to examine how it behaves.
While I agree with most of the things you wrote, I think it’s wrong to assume that only because someone has different things to care of, someone has a life, as you put it, it’s OK to produce crap code.
It’s like you’d say to a truck driver, hey, you have 4 children, just drive as you like, most important is you get home for dinner!
Same as there, we developers also have our written and unwritten rules and guidelines that you should keep at all times.
My problem is, when I see bad code, it’s mostly bad because of sheer carelessness and you can clearly see it. And it is like that for years, even though the original writer is still with the company. If you have a bad day and write bad code, do remember it, spend that extra hour later, go back to tidy it up.
Even if you don’t purposefully do this, you come across every once in a while of your own shitty code. Please at least then take the time for a clean up. Unfortunately most of the programmers don’t bother much.
It’s definitely different when you outsource the code, but later you have to modify the code. My company had outsourced a product, and later hired me to work on it. I ended up re-writing the whole thing.
Sometimes its just easier to rewrite, then to go through the code and “enhance” it. That’s when someone is in big trouble.
I really want to empathize with your intent, but I have difficulty. Either by accident or intent, I’ve spent most of my career cleaning up the crap of other programmers. Many times the empathy was there, the code is crap because they had a compressed release schedule, they had to get something out the door. Or the original “design” did not exist at the time of writing and they had to flounder through conflicting directives. But, many times I end up deciding the original programmers were either incompetent or flimflam artists. If you went to buy a house and found boards nailed all willy-nilly, but the structure was complete, would you try and explain away their incompetence that same way you want to explain away bad code? Or later you found that under the sheetrock half the studs were missing, would you still try to explain away the fraud? I think not. I’ve seen programmers get away with outrageous code, all because you can’t see more than phosphor deep when you look at a program running. I’ve had to deal with programs that barely worked that changes were wanted to “fix that little problem” that were easier dealt with by throwing it away and starting fresh. However that generally runs counter to the perception of the person who wants that “little” change, they don’t want to admit they purchased or oversaw the development of a complete mess. I’ve had to look through programs littered with what I call “debris code”, code that was written with some intent that was never realized and abandoned without being cleaned up. Code that was purposely written in an obscuring manner so the programmer could claim genius status because nobody but them could understand their code. I’ve found code that only worked by accident and the programmer jumped back lest he breathe on it and break it. Obviously they had no idea how it worked, but were satisfied in the narrow range of testing, it worked and that was good enough.
So bottom line is that I have a hard time with the concept that we should walk a mile in their shoes before complaining. I’ve slogged miles and found the destination not worth reaching.
Instead of empathy, I’d rather see education. Retroactive birth control would be too extreme.
Four words:
The Capability Maturity Model
Just as an addendum:
When writing this post I was specifically thinking of ‘how to deal with bad code within a team’. Bad code after the fact, perhaps months into the future, is a different matter.
If anyone is to take anything serious from this I would have it be just this: Don’t berate people for being what you see as incompetent. Seek to understand. Educate them. And try to realise that you will not always be right.
@Endre,
That’s not a useful analogy, IMHO. Lives aren’t at stake in programming (unless you’re in medical/aeronautics etc.). The rules you mention are mostly subjective unproven preferences passed down through formalised style guides and spoken word. What I wanted to put across in the post is that: Not everything you think is incorrect is in fact incorrect — many times it’ll be a mere preference of yours.
And if it is truly carelessness then wouldn’t it be best to explore why the programmer was careless? The bad code is a symptom of something deeper that’s worth investigating, IMHO.
@BlaiseP,
That’s still a form of education…
Yes, you’re better. But you’re also probably not too great at other things. My point is that: sure, you’re good at that stuff now, but you’re not good at everything, so being humble wouldn’t hurt.
@Curt,
I don’t think this analogy counts for the specific area I was trying to write about — that of handling bad code within a team. I don’t have a business contract set up with each individual colleague. I’m not going to berate a fellow programmer with “Hey, you were paid to produce less shit things, wtf” — that would be a terrible way to deal with people.
The point is, if someone is found to be incompetent, there’ll be a reason. E.g. Lack of domain overview, lack of experience on that specific tech-stack, lack of time, lack of interest/motivation.
Crapness does not exist in a vacuum. The influences need to be considered.
Why not both? A little empathy doesn’t hurt.
I can forgive bugs, badly written code, but what I can’t forgive is bad code, bugs and no comments. The only crime I know worthy of capital punishment.
…. Capital punishment is where you have to write code using only CAPITALS!
and we have a special keyboard for that!
don’t be the guy that replaces the spaghetti with elegant simple code that doesn’t work because you don’t know the dirty secrets about the domain.
The fact that there aren’t lives at stake doesn’t mean it’s fine to neglect basic rules, sometimes even common sense. You can adjust that analogy to a baker as well. If the bread aren’t all the same size and taste, and here and there a piece of hair or a dead mouse in it, you won’t buy it. Now you can say, yes, but the customer doesn’t see the underlying code, if the application works, it’s OK. No, it isn’t OK.
I agree, a little empathy doesn’t hurt. I get your point. I’m just fed up with people I was forced to work with and were constantly careless over years. Advice resistant, lazy and rude if you show up to them to discuss your concerns. And there were a lot of these. Maybe I’m just unlucky with the teams I’ve been working with and it’s different at other places.
The only difference between good code and bad code, is that bad code isn’t written the way you’d expect, for what it’s doing. Always consider the possibility that you might not have the full story of what it’s doing. If you can’t see a technical reason for it, ask the developer. But, ask non-confrontationally, less “Hey Joe, why’d you write this steaming pile of * this way?” and more “Joe, do you recall why you wrote this code this way?”. The former will usually get the most face-saving answer, whereas the latter will ocassionaly educate you.
If you spend a huge amount of time rewriting other peoples code (recluctantly or otherwise) year after year then maybe you need to ask yourself why.
I’ve been the guy who replaced the spaghetti, no matter where or when I found it, with elegant, simple code (that didn’t always work). I’ve been the compulsive rewriter in every workplace I’ve been in.
Three years ago one of my sons was diagnosed as having Aspergers. I was “No he doesn’t – he’s just like me.” Now I realize he does, and he is. And I try to wind back those cracked up little monkeys in my head that make my brain hurt like it’s pickling in a jar of acid and rusted scrap metal when I look at code that stylistically differs from mine more than a little bit.
Rewriting crapsack code is part of coding. But if you’re doing it all the time, in every workplace you go to, maybe you need to step back. Take a breath. Spend some of that time on excercises to expand your own cognitive tolerance levels instead. Then take another look. Just saying.
Awesome man – loved the Educate part!
It makes a lot of sense to write a blog post like this then!
Awesome article!..sometiems i wrote bad codes.. I didn’t concern about that.
Brilliant post, thank you!
…but where would we programmers be without that visceral, cathartic release provided by abusing other programmers to their faces…?!!
Good article! It’s a shame that it happens so often, though…
“Seriously, you’re crap too”. Why is this the hardest thing to grasp for many of us? 🙂
I think that before educating others, we must educate ourselves. I reached the conclusion that it’s pointless to get angry and yell at people for making mistakes, nothing will be solved.
If someone from the team wrote “bad code” and you are the one who has to deal with him, have a little conversation and make sure that the next time he won’t make the same mistakes, but try the slice of humble pie during that conversation. 🙂
Hello James,
This reading put me on thinking.
Besides being a science, the programming is also a continue developing, both in personal terms and in its scientific field. Considering a specific piece of code as being bad should be put firstly at the same level of thinking as it was made.
To be more clear, if someone in the past has made a great code for his/her level of knowledge and for that specific time language capabilities, in the present day it could be viewed as a primitive and rigid programming. But that does not mean at all it is a bad code by essence, but merely it is outdated. What do you think?
“It’s dead easy to understand.”
This is where you have it all wrong. If it’s easy to understand, it’s not a problem.
The biggest problem of messy, disorganised, bloated and otherwise poor code is exactly that it cannot be easily understood. It may lack structure, organisation and consistency. Program flow may be poor and convoluted. Code is generally buggy causing data integrity failure and a failure to handle anything but the most common or expected data. It may be superfluous and simply hard to read through atrocious formatting.
“Seriously, you’re crap too”
I would not say so. I make mistakes but am never responsible for the above. I do not know how it is even possible for some people to code so messily.
So often I’ve replaces a hundred lines of code with ten that are faster, more reliable, more accurate, bug free do at least as much as the original code, etc.