We Swim in Clean Code is something of a slogan you’ll see upon visiting our website. I don’t remember the exact genesis – there were lots of ideas floating around when we were creating the site content, and, honestly, being Savvy Otter, the phrase was probably a gimmie from the start. But the thing is, it’s not just marketing text. Definitely not.
Spend any time in these halls and you’ll come to realize we believe in the art of software construction, doing it right, but while not getting into an endless (and wasteful) cycle of perfectionism. That said, one of the tenets at the center of this belief is that code is written once, yet is read 10,000 times. Ok, I’m exaggerating a little, but not much. The consequence of that reality is that code needs to be easy to read and understand by ALL who have the fortune or misfortune of seeing it. Put another way, code should be optimized for reading and understandability and, perhaps counter to what some might think, NOT for keystroke speed / shortest time to finish line. Here’s a few points about the characteristics of clean / unclean code.
Unclean Code is
- Hard to understand. It slows everyone down. The mental effort understanding it takes away from the task at hand – usually trying to track down some bug (as you’ll see below), but also hurts you when trying to make improvements / changes. Successful projects require predictable outcomes and an important part of that equation is efficiency. People, for some reason (you know the ones – those with pesky expectations and all that), would rather pay developers for productive work and get unhappy when progress is slower than expected. Slogging through unclean code is 100% a contributing factor.
- A place where bugs hide. I’ll likely make a post on a later date about the value of code inspections, so I won’t spoil that, but I will say that it’s often impossible to spot bugs in unclean code. The converse is that it is super super easy to spot them in clean code. The number of times someone asked me to build software with lots of bugs is so astonishingly low even a unsavvy otter could count that high. That number is 0.000000 – with 6 decimal places.
Clean Code is
- Spoiler – Easy to understand. The intent is clear. You can read this code and quickly do the mental task of making sure it does the thing it’s supposed to do. You feel safe to concentrate on your task and can worry less about breaking things as you go. You’re probably 37 times faster than you’d otherwise be. Your projects don’t get bogged down. Clients are happy and handing out high fives like banks handout lollipops – or they used to. By the way, if you want to make fast friends – I’m a sucker for a Charms Pop. And yes I slipped in a dad joke there. Guilty.
- If I’m being 100% intellectually honest, the other benefits really follow from “easy to understand”. So… Clean Code is also
- Less forgiving of bugs. Bugs can’t hide in code that is easy to understand. When someone reads that code many common bugs are trivial to spot.
- Easier to modify without breaking it. We’ve seen companies and individual struggle with this. They go to fix / change something and in the process create 10 problems along the way. When this becomes a pattern code quality can be a factor. The code is not clean.
- Faster. Literature points to clean code executing up to 89% faster than unclean code. Ha ha. No. That would be amazing though if true. By faster, I mean teams can work faster in a code-base that is clean. Faster teams – faster projects – kept timelines – better outcomes.
I cannot say enough about clean code and why it’s so vital, but the tyrannical marketing person who’s holding a gun to my head to finally commit this post is already itching for my next assignment, so… luckily people write books on this subject and have done the topic better justice – in my 20 years writing software, I’ve read more than a few and some of those I’ve read multiple times. If you’re interested in learning more, consider looking at these.
Code Complete – click here to purchase
Clean Code – click here to purchase
