This code sucks

Why you should care #

Developers tend to be an opinionated bunch. After all, it’s far easier to recognize bad code than it is to write good code. I imagine this isn’t unique to writing code, but rather a shared experience in most professions. Writers will read this post and think what a fucking idiot. He didn’t even use quotes right. Or OMG what a worn out trope. Artists see sketches and criticize the shading. Designers see logos and mock the typeface.

Anyway what I’m getting at is that it’s fairly common to criticize the very codebase you’re working on. Criticism ranges from thoughtful, constructive criticism to immature whining. The scope of criticism can be a couple of lines, a class, one entire layer of the app or the whole damn codebase. I’ve worked in more than one company where developers were calling for a complete rewrite.

If you’re in any sort of leadership position, you should always approach these comments with some measure of skepticism but also a mind open to budgeting time to improve your product’s internals.

• Is the developer just having a bad day?
• Are they over-reacting?
• Is it a simple disagreement over style?
• Are they just being a whiny little bitch?

Sometimes developers simply need to get over themselves. There are many ways to write any given method and many ways to solve any given problem. The other thing young developers need to realize is often times the author of the code they’re complaining loudly about is a senior developer within earshot or possibly even their boss. Maybe that code sucks, but it might be advisable to think about the way in which you are expressing your opinion.

That said, developers are frequently pressured to cut corners and ship products faster. It is important to maintain a readable codebase, because code is typically written once and then read hundreds of times (disclaimer: unless you start out with a formal decision to follow a style guideline, I doubt it would be worth the effort to convert mature codebases into a consistent style).

Furthermore the age of “test everything” has led to a cruft nightmare in codebases. Testing colors, images, price points is one thing. But testing an entire feature in a webapp leads to forgotten code laying around. Keep in mind every feature consists of code on the server (eg, Ruby), HTML, CSS & Javascript. All this code is spread across many files. So when you rip out variations A & C through F of your hot new feature, there’s a lot to remember to clean up. Most of the time, developers delete a few lines (or worse yet, comment out a few lines) and leave the rest. Soon your codebase could be featured in an episode of hoarders.

Features, quality, deadline. Choose two.

This is often forgotten in the rush of new ideas and shortening runways.

When you decide your developers aren’t just being babies, you need to make one more important decision.

Are these developers capable of doing better?

I think that the answer is typically “yes”, but not always. It is extremely important that you determine what it is in your particular circumstance.

Assuming that your developers are in fact capable of doing better, the next thing you need to decide is whether or not you care about the future of your company. Don’t scoff — the very future of your company hangs in the balance.

Working in a codebase with extensive technical debt has a lot of downsides for your company: #

• affects morale
• slows team velocity
• penalizes performance
• leads to shipping bugs, and
• ultimately further propels your code into the garbage thanks to the Broken Window Theory

As your code gets worse and worse, customers will be affected and leave, and developers will realize they can work at one of a thousand other “hot startups” with good compensation and perks.

If you don’t code, imagine for a moment that you have been tasked with painting a wall in a house. The first thing you have to do is scrape the old peeling paint off the wall. When you do, you find deteriorating sheetrock. When you pull off a patch of sheetrock, you find rotting studs. When you cut out the studs, you get to the foundation and realize it’s gravel on quicksand. HEY!! WHEN ARE YOU GONNA BE DONE PAINTING THAT WALL?!?! Next we have to replace the light fixtures—please supply a time estimate.

While the Boy Scout idea of “leaving someplace better than when you found it” can go a long way toward fixing style issues or codebases that just have a few problems here and there, it does nothing for major architectural problems or bad inertia created by developers not following best practices.

Can you afford to take a week or three to rewrite major pieces of your infrastructure? Only you can make that call. The question I’d like you to ask yourself is can you afford to lose your developers? Can you afford to ship bugs? Can you afford to shoot yourself in the foot next time you want to hire developers?

If your code has major problems, you shouldn’t be asking “if” you should budget time to rewrite the affected portions, but rather “when”.