Before starting a new development phase, it’s worth spending some time improving what is already there.
Building a high-quality piece of code is an incremental process. The first thing you write—though it works—never, absolutely never, has the quality it needs to ensure maintainability.
It’s becoming a recurring experience for me to analyze projects that, for one reason or another, end up being difficult or impossible to continue evolving. It doesn’t matter which technology is used, although some have traditionally led to more badly deteriorated projects—that is, projects that eventually have to be rewritten from scratch. PHP, for example, tends to lead to this, but not because of the language itself. Its learning curve is so gentle that someone new to programming can get results in very little time without even needing to use object-oriented programming. Over time, the application keeps growing without establishing design principles, good practices, proper configuration management, or clean code. In other words, a complete nightmare. Object-oriented programming tends to encourage a somewhat better design, though there’s a lot more to say about that.
At first glance, you can often tell whether the design has been carefully considered and reviewed—if a “design” exists at all, rather than an excessively monolithic system—as well as assess the structure and quality of the code in each method.
It’s just like writing a story: first you start with a draft (and yes, it “works” in the sense that it conveys the idea you want to share). If you read it through, you’ll probably find a punctuation, spelling, or grammar mistake, and you’ll almost certainly spot paragraphs you can improve on that second read. The same thing happens in a third review, until eventually you sense that the quality of what you’ve written meets your expectations—perhaps after the fifth, sixth, or tenth proofreading pass. Even more so if other people read your text and find subtle typos you overlooked.
Software is no different, except that these reviews affect both the code’s structure (its design) and its flaws: excessive coupling, low cohesion, duplication, violations of design principles, hard-to-understand code, insufficient tests, and so on. The question is: why should I care about all this if my application works? Hmm…
If you’re developing an application that will never need to change, you could deliver it with every flaw you can think of. But that rarely happens, because most projects will undergo changes to a greater or lesser degree.
I’ve seen so many applications that are little more than extensions of an excessively monolithic core… until the point when it can no longer support more changes and has to be thrown away and rebuilt from scratch. That’s frustrating (or perhaps a relief—who knows) for the developers, and a blow to the business, which incurs extra costs, while someone in charge tries to dodge responsibility.
The way to avoid this is to continuously refine the application you’re working on, improving all the aspects that software engineering tells us contribute to code quality. By quality, I mean building an application that’s maintainable, supports automated tests, and is easy to modify and extend.
It’s surprising how many of these refinements are straightforward and can be done quickly. The benefits they bring in the medium and long term are just as surprising. Here are a few examples:
- Check that the code follows clean code best practices (good names, correct indentation, short classes, and comments limited to what’s necessary).
- Check class cohesion to help ensure a good design.
- Are the S.O.L.I.D. principles being applied correctly?
- Refactor small parts of the application to improve its design and make it simpler.
- Take another look at the most complex business logic and simplify it wherever possible.
- Review whether the deployment process can be improved further.
- And so on.
It’s a good idea to spend some time on all of the above before starting a new development phase. Doing so will very likely reduce the time needed to add the new features we’re about to work on.