Who wrote this sh*tty code?
A CTO and a dev are looking at the legacy codebase to fix a bug. After the endless torment, they are about to give up. Who wrote this shit, asked the CTO. Flustered, he checked git blame, and the answer was him.
Meet our hero Jake. He is a developer freshly employed on a project that is six years old. During the onboarding period, Jake got to fix a bug which required him to dwell in the depths of the legacy code. He armed himself with knowledge and context and he entered the void. Everything should be easy to solve. It’s an onboarding task, after all. What might go wrong? **Apply cynic laughter here.**
After the first two hours, Jake has depleted all the excitement he had. He caught himself in a cobweb of frustration while trying to figure out all mix-in hierarchies, more complicated than a royal family tree. Long methods that are doing many things. A crippling implicits hidden in the dark corners. He viciously fought all genius’s brain dump, but in vain. The doubt and anxiety covered him like a morning dew, or was it a sweat? Is the guy who wrote this a complete genius, or is he just an asshole? Jake didn’t like the legacy code at all. The codebase didn’t match his code style. Every single red-flag lighten up trying to figure out what is going on. This is horrible. We should rewrite this at once.
Most of the people have been there as Jake. To feel the urge to rewrite something that doesn’t match your code religion. All you see is blasphemy of the clean code. It itches you to throw another rock at the already broken window, just in spite. How could you adapt that horrible code style and do some fixes? Well, it’s ok to feel that way. Yet again, you certainly don’t know the context why someone made these decisions. Try to understand what was behind motive before you judge and get consumed by your ego. Maybe there was a tight schedule which made them take shortcuts. If it’s startup, they’ll address tech debt after the burning phase. They might need investments to continue project, happens all the time. Another reason could be that they started simple, but the requirements made them converge to something more complex, which is yet the simplest approach at that point in time, optimized for cost and speed? Maybe they didn’t use any flashy tech because it wasn’t stable enough and there were no alternatives? What else could be the cause? Someone’s arrogance? It is sad, but the arrogance is a common cause. Or simply, they didn’t know any better. It’s not a sin after all. One of my colleague has said:
“Everyone writes the best code they can at that point in time, given all circumstances.”
We can go on and on, but it would be too expensive and risky to rewrite everything from scratches. I worked on a project that we developers thought it was unbearable with shit storm of the codebase. We cried and complained and refused to take a responsibility, but asking for complete system rewrite. For every bug we blamed the codebase, tight schedule, but never us. We were loud enough and got the opportunity to rewrote everything. Did I forget to tell you that was a startup in desperate need for the investments? Of course, halfway through, the startup lost its momentum to gain investments, and the project has run out of funding. But we’ve done it by the book that time and by the book we’ve failed.
Endnote
It sure is unfulfilling and tiresome working on the lame codebase. Resisting the urge to rewrite something that you didn’t write is a skill that a young developer rarely has. Instead of understanding the problem and the client, you want to prove to yourself and you forget what is the project really about. What ever you do, there will always be a crap in the codebase. So what could you do to fix it? For starter, don’t complain. No one wants to listen to that, nor they want to listen that they made a mess. You wouldn’t like it either. Start with boy scout rule and leave the place cleaner after each visit. Fix a broken window when you got a time, learn others to fix them too. Add a test before fixing a bug and after some time you will be more confident about changing or refactoring something. Make an example to everyone that, bit by bit, you can all contribute and make a codebase a better place. It won’t happen overnight, but after sometime none would recognize it. If it is really horrible, point out what it is and why do you think it is horrible? How would it reflect business by fixing or not fixing it? Make a short- and long-term plan for what you could improve, so you always bring a value. And remember, the next firefighting and rush could happen anytime, but don’t be afraid to take a shortcut if you communicate it properly that you would need to return and fix it after the fire is over. After all, you won’t get overweight by eating an extra cake on holidays, but by eating an extra cake each day.
