It shouldn’t be a secret, in fact I don’t want it to be a secret.

This so called “art” can define the future of your application, the sanity of your team, or worse, the future of your company.

Am I exaggerating ?

Not really. If you are a programmer with a few years of experience you’ve probably already seen this countless times, hell, you’ve probably done this already which is the so called messy, undocumented, untested and hard to read code.

Here’s a fictional story that I know lots of you can relate.

Meet Foo Inc.

The Foo Inc. company is about to release this new amazing app.

In the beginning everything was fine and dandy, the software appears to run, so the managers were happy. The developers know they could’ve do much better job than this but it’s to late to refactor, that would mean to create everything from scratch. Yes, they didn’t follow good development methodologies because they thought it was too boring and it wasn’t really that necessary.

And over time, their code is getting bigger, fattier, ugly and buggier, to the point that when a new change it’s needed a new bug pops out from some other place. So they quickly patch it, to get it over with it, and fingers are crossed.

So, the next time a new feature it’s added, they go back to that glue-patched-cryptic code and add more spaghetti code. At this stage some of them think it doesn’t even matter anymore, they just want to add that functionality to that beast and get the hell out.

Developers get demoralised, and eventually some of them quit. So the company has to replace them. They hire new people. But since this app code is uncommented, patched to the bones and cryptic, the new developers have hard time understanding it, so they talk to the managers and decide that they need to start over, a clean slate.

Now you can see where this is heading. There’s a new buzz in the company, and every developer wants to be part of this new “version”. It’s a breeze of fresh air, it’s like starting over. But it’s getting worse, because now they have two versions to maintain and nobody want’s to be part of the “old” code team.

So this company is spending more money, more resources into something that should be done right from the start if they enforced their developers into using good coding practices.

To some companies, this could be their end, the first version of the software could be so bad that they don’t have any more money to hire new developers or create a new version from scratch, because they got not clients for the fact that the first version had so many bugs that nobody bought it.

So…what’s clean code ?

Clean code it’s when you read it and you know the developer cared.
When it runs all the tests, it’s well documented, meaningful function, classes and variable names are used, it avoids code duplication. It’s when software methodologies are in place. In the end, clean code it’s when you learn how it works by just looking at it.

This is not something you learn from day one, it’s something your learn over the years. It requires practice and good taste, and this it’s why it’s called “Art”.

Explain to your team and your company why this is so important, why it’s important to use good coding practices and extend the deadline if needed in order to make your code better.

I’ve read this in the “Clean Code” book once:

Leave the campground cleaner than you found it

It really represents the Art Of Clean code mantra.