Wait a second, does code quality even matter?

Wait a second, does code quality even matter?

I once had contact with a project that ... well it wasn't the nicest piece of code I've seen. That got me thinking. I tried to compare this codebase with other projects I've worked on, even going back to times when I was a junior and learning by diving deep into topics I didn't know. So join me on this thought experiment, at the end of the article come up with your own outcome.

Can you adapt to a code style?

Can you adapt to a code style?

Setting the scene: Imagine a project you are taking over, you roughly know what it's about and have seen some of the code. Are you really able to adapt to the style guide, the processes and continue writing the code as it was written by your predecessor?

Very often, when you take over a project, or are tasked with a redesign, or simply a medior joins your team. What's the first thing that comes to mind?

Yup, this code is shit lets rewrite it

But why is that the instinct reaction? Is it because you are not familiar with every nook and cranny of the system?
I think it's about something else. Writing code is like writing a book. Developers use words from a framework (dictionary) and create stories (applications) where there is a plot (goal/conversion). The thing is, that you are not J.K Rowling, Stephan King or J.R.R. Tolkien, you cannot continue the next series of Harry Potter or write a Hobbits tale.
The environment, the feel, the style is something unique to these authors. You are able to mimic and get close to their style but you'll never match it 1:1. And even if you mimic it, will you feel at home with this code? Are you not just trying to be someone you are not.

"So it's only natural that you start to write code and sprinkle in your own style"

Every developer is different and will write his code differently from others, even if tasked with the same project. I much enjoyed the CSS battle which clearly shows different routes, ideas and skills that finally achieve the same goal. Which method was better? It's hard to determine.

So it's only natural that you start to write code and sprinkle in your own style. Is this a bad thing? No. Everyone wants to feel comfortable and write how they feel is correct. Most of the time it doesn't matter how you name your variable, as long as it properly describes what it's doing. When reviewing code I focus on the logic, check for performance issues, fallbacks or redundancy. Rarely do I correct someones variable name, placement or style of code.

What is code quality anyway?

What is code quality anyway?

There are a great deal of websites and apps that are built low cost with an endless supply of cheap students. Functionalities built entirely on copy pasted code from Stackoverflow*.

* I once reviewed an assignment from a candidate, where next to all of the code was in a different style, naming conventions mixed, everything felt wrong. I soon realised the entire assignment was just snippets of code directly copy pasted from Stackoverflow and I was able to locate the snippets just by searching for them. Needless to say I swiftly rejected the submission, but in some way the assignment was done and the functions kinda worked.

There are platforms with no abstraction, just copy pasted again and again the same functions, features and pages. There are websites that have code written in polish (and have become memes because of it) or other non-english languages. Some have admin panels secured with credentials: Admin, Admin. Others don't display correctly on mobile devices and have bad UX practices or loaded with 3rd party plugins, that sometimes arn't even used.

The fascinating part of all of this, is that these sites are running, they are making someone money. They may be carts with square wheels but they are pulling their weight and moving forward reaching their goals. How?

Why does every lead developer, HR specialist, code reviewer mention code quality and that everything needs to be written tip top and perfect, when a simple stopgap, duct tape and chewing gum alternative will work just fine.

"Nothing will happen! But also nothing will change."

If a developer doesn't document his code, nothing will happen. It'll just take a bit more time to get another developer on the same page.

If you don't make tests, don't apply a bug tracker, don't review what your users are actually doing on your platform, nothing will happen. You'll have bugs that probably will only affect a small % of user, you won't even know (or care?) about.

If you copy functionalities or pages instead of making them abstract and adaptable, nothing will happen. If you request a change in all these pages a developer will need to remember to go over every single copy and sometimes you might miss a spot that also needs the tweak.

If you make something suboptimal, don't fix data leaks or redundant code/functions, nothing will happen. Your users will have to wait longer, see a loading spinner, maybe their Chrome tab will freeze. If it is a server bottleneck, just buy more expensive additional RAM or workers or just add more servers.

If your page is not RWD, responsive on mobile devices, nothing will happen. Your users might have a hard time reading something, they might get the dreaded horizontal scrollbar, some might drop off, but if they really want to use your product they'll keep at it and just work around issues. (or ultimately just go on a desktop device).

If your devs or stakeholders refuse to update to a modern code standard or modern framework, nothing will happen. You can still use jQuery, Angular.js, generate HTML files and upload them to your server via FTP. You won't have the latest iPhone, but your current iPhone 4 still works fine, and makes calls and receives MMS, so is there a real reason to switch up?

If you don't uphold a healthy dev environment, nothing will happen. People can be easily replaced. If they get burnt out or "can't handle you at your worst" then there is an endless supply of young matchstick developers that will gladly burn out for your company.

Will your code eventually go to the bin?

Will your code eventually go to the bin?

Now obviously I know very well why upholding a good code quality is better, especially in the long run. But is there a long run?

Usually after a couple years, your CEO or PO decides it's time for a visual refresh. Redesigns usually mean flipping everything upside down, so starting scratch is on the menu. A couple years have passed and that framework you are using released a new major version, usually not backwards compatible with your version. Or there has been a revolution and you'd really like SSR capabilities, which often means rewriting from scratch.

So what happens with that beautifully created code? Documented, sealed and reviewed, tested, improved. It goes in the bin. Well ... maybe to recycling. Some of the really nice core parts you'll most probably want to keep.

I speak mostly for the frontend but I'm pretty sure that on the backend things look similar. I've had situations where I created a smart component that recursively handled nested lists and adapted to any depth. I spent some time on it, I knew this was an important feature for the business. But a year later the list was reduced to a simple flat list.

"At the end of the day ... You need to find the sweet spot"

Also at the end of the day ... is night.

I assume code quality is more about being proud of your work. You can glue together a Warhammer figure, paint it and use it on the table top, or you can scrape mould lines off, sand the model, fill gaps, prime it, paint it, decorate the base and either use it in battle or place it in a display case.

This is the tricky part, because my definition of good quality code is different from your good quality of code. What I think is readable and well separated into config files and components might be hard for you to understand because you prefer having larger components with everything in one spot.

I guess, what I'm trying to say, is that the longer you are in IT the more you value pragmatism. You don't need perfect, you need "Good Enough". There are no perfect clients, projects, processes or code. You will always find someone that will want to rebuilt the entire thing just because he's joining (and most of the time he should).

I could continue, I could balance this article and explain why its worth doing your best. But since this is meant to be a thought experiment, go back and think about projects you've been in or apps you've used. Which of them totally sucked, but are still on the market and still shredding the tarmac with their square wheels. And ask yourself, "Does code quality even matter?"