In search of the perfect code

If you spent long enough in the IT industry, there is a chance you came across people with different views on how code should look like.

People sometimes become very passionate about their code and the practices they adopt. This could be both a blessing and a pain. A blessing because this is a very good chance to learn new ideas, improve practices and also, importantly, to bond. A pain because sometimes it’s difficult to reach a compromise and keep the team moving ahead while keeping all members happy.

I’m not going to talk about how to code or which practices you should adopt but how to avoid getting entangled into all these IT buzz words while keeping your team focused on delivery, code quality improvement and innovation.

Good code quality reduces cost over time by enabling developers to make code changes easier and faster. This will increase team productivity and also keep team members happy. Nobody wants to spend hours investigating every unexpected dependency every time when a code change is needed.

But how does good quality code look like? I think this is still open to debate. Industry has been trying to improve over the years and a lot of concepts have been thrown onto the market: waterfall, TDD, patterns etc. All good ideas at their time, eagerly adopted by companies and developers alike, which have proved “improvable” over the years. Agile is replacing waterfall, TDD is widely used but there are already people who are talking against it after years of using it, singleton pattern is considered anti-pattern since IoC containers do a better job, just to name few.

IT is a very alive industry. New technologies and ideas come to the market every year while others are slowly abandoned as obsolete. It is understandable people have different views and expectations. This is why anyone working in IT should be open to look into new technologies and ideas and embrace the ones which fits better their needs.

So how can one make decisions in this “chaotic” environment? Think in terms of cost-benefit. Adoption, migration come with a cost but might help you save more in time. A heterogeneous system might prove difficult to maintain but one where technologies and methodologies are rigidly enforced might be a innovation killer. New doesn’t necessarily mean better. New means untested but also means opportunities.

Adoption of new technologies should be based exclusively on necessity. Give yourself some time to understand how it could help you and how much will cost you. Not everything out there is for everybody and sometimes timing could be an important factor. Micro-services sounds great in developers’ ears but you wouldn’t start a new project by creating a bunch of them.

Nevertheless innovation is key. We need to keep improving our code and practices. This will lead to more heterogeneous systems since different parts will be updated at different times but the alternative might be slow innovation and more legacy code.

Working with legacy code is sometimes as fascinating as reading history. In a way, we are just writing today’s history for the next developers generation. I can only hope they will enjoy reading (using) it.

Are you still looking for the perfect code? Keep looking. Maybe this is what drives this frenzy in IT. In the meantime, until you find it, be open, adapt, try often and fail fast.