We forget the basics

Nowadays we programmers are just too busy keeping up with new languages, frameworks tools and technologies and sometimes we forget some of the pillars that our profession is built upon.

Specially when it comes to the daily job we can get sloppy or just plain lazy when working on a new design or a “simple new case” on an existing functionality. The danger here is that in code, as in every system, entropy tends to increase making the code rot.

This entropy increase usually comes in the shape of small changes due to requirements that where not defined in the initial scope of the system or were not taking into account when a module was first designed. This trend can even get amplified when using agile methodologies and iterative processes if some parts of the system are created as afterthoughts.

Not all is lost though, software rot is a reality that has always been there, but so have had the tools to fight it. Good design practices like maximising the software cohesion and reducing the coupling between modules provide a great benefit regardless of the programming language where they are applied. Also, the adequate usage of known design patterns helps to increase the code’s quality while keeping it simple for other programmers as they are more likely to be familiar with the same design patterns.

But even when a software project is started with the best designs in mind it’s still very likely that at some point of it’s life it takes the wrong path due to pressing deadlines, some unfortunate late Friday commits or just slow degradation. How can we rectify this?

In my opinion the answer is to refactor, I know it is a dirty word for many and it has caused a lot of suffering, but we must lose fear to it, it is not a painful experience because it’s a bad thing to do, it is so because we don’t do it often enough. Refactoring must be done from the early stages of any project and it must be done continuously throughout its life to ensure the code is kept to the highest standard we can realistically achieve.

This requires a big commitment from the team members and if working within a company, trust from management on the development team and a propitious environment that encourages teams and individuals to create excellent code and not finishing business requirements. This might at first seem counterproductive as what the business needs will always be those requirements to be delivered as soon as possible, but when looking at the big picture of the whole life cycle of a software project early investments that increase the software’s quality will reduce the overall cost, as well as the perception of quality from the business, the clients and the developers themselves.

I think that the software developer profession is lacking in maturity and that although we are constantly trying to find ways to improve our technique we constantly stop focusing in the big picture and get too excited about new technologies that are just temporary and will be replaced soon. As professionals we have to always remind ourselves from time to time what is that makes good software.

Let’s refactor ourselves.