On software complexity

Ok, I'm probably just thick. Or, after writing code for so many years, I'm still not good at it. Or am I? Today's post is the result of esoteric thinking. Thoughts that go through your mind when faced with really complex code or, in other words: "what the hell does this thing even do" questions. Complex code should not be confused with complex business logic and complicated workflows.

There are a lot of smart developers out there. A lot smarter than me. You may be one of them. How you write you code says a lot about you and your skills. Most people, write code in a certain way and they usual adjsust their style slightly to fit with an existing codebase or team "coding standards". "Coding standards" is in quotes because each team has its own coding standards. However, there are some developers that are too clever. The ones that write code that makes you wonder if what you're looking makes any sense at all. That's because the code is too obscure, too compressed, too concise, too..."clever". In the end, it's just too complicated

So what do you do in cases like this? You usually have to go line by line and if you're lucky, there may be some unit tests to help you get a better understanding. Or you can debug the code and break at a point that will allow you to step through said piece of code to try and make heads or tails of it. It's definitely time consuming and, in cases, tiring trying to figure out what the code does before you even add your own piece into it. Or worse, fix a bug.

"Clever" code or "show off" code is bad! Bad for the person that writes it and even worse for the person(s) that has to maintain it. If your goal is to impress your colleagues with your coding skills, don't do it on production code. Write a Kata, put it on GitHub and invite people to comment or take part in Hackathons and come "home" with the trophy. But never on code that's destined to run in production. Because if you do it on production code, you're sabotaging the project and your team. Not everyone is at same coding level as you or shares the same mindset when it comes to implementing something. There is also a very good chance that you wont be around for ever to maintain that obscure service, helper, framework or whatever it is that you built. Leaving bad code behind will make everyone's life miserable.

For me, programmers are responsible for writing good, readable and clean code. Bonus points if it works (just kidding)! Now, let's pay attention to the word "readable". Can a junior developer in your team read and understand your code? Then in that case your code is more than clever. Your code is usable and functional and this, my friends, is the biggest asset in any codebase. If people are afraid to touch your code because they have no clue what it does or how it does it, then it's magic. Not the good kind of magic, see SignalR, but the bad kind of magic that people used to "burn on a stick".

After all these years, I always favor clean and simple code over clever and obscure. Your colleagues and successors will be eternally grateful for your legacy. And instead of thinking how to rewrite that module you wrote 2 years ago, they will use it and work with it to make it better.

If you ever find yourself questioning the simplicity of your code think hard about what kind of legacy you want to leave behind.

Image credit: alphaspirit/Shutterstock