loading...
Cover image for Even bad code is valuable

Even bad code is valuable

xoubaman profile image Carlos Gándara ・3 min read

A usual scenario: you join a new project, start to browse the existing code, and quickly realize a hard time is coming.

Code is ugly, poorly designed, hard to read, overengineered, untested,... you name it.

And you start to curse. Your luck, the guy who did this in the first place, the world, and that variable named resultFromQueryTwo.

Well, I am here to say: don't do that. It is bad for you and your environment.

For even the most hideous code there is always a reason behind and value to be found.

Everything is done in a context

We had a deadline

When you sit, as the new guy checking the project, calmly browsing files, it is hard to understand why somebody could ever write such an obnoxious code.

Deadlines, hacks to solve a burning bug, lack of inspiration,... there are plenty of causes to produce code that is not good and nobody is safe from them.

Maybe you can empathize a bit with the poor guy that wrote such an ugly function two years ago. Maybe that poor guy was you!

Always assume the prime directive: each decision wast the best thing to do in the given moment within its given context.

A bad design is a necessary step for a better one

It wasn't that easy

Any implementation we code is based on the knowledge we have at that moment. The very process of coding a solution increases our knowledge about the subject, allowing us to improve it in further iterations.

Think about inherited legacy code as an intermediate step to a better design, done with more knowledge. It is just that the guy before you did not have time to iterate over it.

At least you have some kind of spec

It's something

Inherited, not fancy code can be hard to understand, untested, twisted,... but somehow it works. Even more, in a lot of cases, it is the main source of revenue for the company.

Figuring out what a tangled piece of code does can be a challenging and painful process. Once you achieve it, significative paths are open in front of you.

You can improve it. You can replace it with a better-designed solution. You can confront it with what the business people think the system should do -it is amazing the amount of times code behavior and business expected behavior diverge.

But, most importantly, now you know what's going on. There is something happening and the current code is the Rosetta Stone to know what.

Endless, pointless complaints

Maybe a little bit of initial whining can be therapeutical. Even some cursing from time to time. But that's it.

Keep in mind that this obnoxious codebase you inherited is a valuable tool, that you might be producing similar code in the near future and that most likely you already did it in the past.

Empathize, stop complaining about the problem, and move on to find a solution with what you have at hand.

The cover image was taken from Your world t-shirt

Posted on by:

xoubaman profile

Carlos Gándara

@xoubaman

I do software, mainly with PHP. Also I read about it. And I think about it.

Discussion

markdown guide
 

I've found that usually the context is inexperience or rushed timelines. Those do not make the bad code "valuable", they make it technical debt.

this obnoxious codebase you inherited is a valuable tool, that you might be producing similar code in the near future

I'd argue this is a bad thing.

 

Fair point, usually bad code equals to technical debt. Still, it is more than nothing at all and you can use it as some kind of primal spec or starting point.

Regarding the quote, the context is how pointless is to complain or blame the author. It is not uncommon at all to go to the commit introducing the changes and find out the author is... yourself.

Thanks for the comments!

 

the context is how pointless is to complain or blame the author

Fully agree. It is toxic to do so and leads to tensions in a new workplace (especially if the author was liked or still employed there!)