Rotting Design

Properly maintaining an enterprise application

I’ve been a Java engineer at Cognizant Softvision for the past six and a half years. I tend to believe I was born to be a programmer given the fact I was born on 13th of September, which is the 256th day of the year, and as you may already know, this day is International Programmers’ Day. 

This year was my first experience presenting at Programmers’ Week, a week-long Cognizant Softvision event that celebrates the aforementioned special day. The week is filled with sensational talks. You will find many inspiring articles related to this event on our Insights blog, and I’m proud to add mine to the list with highlights of my presentation.

We, as developers, have to pay a lot of attention to continuously improving ourselves and the applications we are developing. So, while my topic was not necessarily a new one, it is certainly a phenomenon that continuously appears in enterprise software and there are several reasons why software rot is important to address:

  • It has been 20 years since Robert Martin (a.k.a. “Uncle Bob”) introduced the SOLID principles and we still tend to “avoid” them.
  • We live by the words, “If it works, don’t change it” and in constant fear of refactoring the code.
  • The cost of bug fixing increases over time if we do not put extra effort into writing clean code.

What is software rot?

A quick description of software rot would be: a hard to maintain code base, very complex, with obsolete architecture and design, with modules and components really tight coupled. Generally, it occurs when it’s difficult to implement simple changes and often comes with many other hidden issues.

The four symptoms of rotting code, as defined by Robert C. Martin, are rigidity, fragility, immobility, and viscosity. Learn more about these symptoms in Martin’s book, Design Principles and Design Patterns or through this article on medium.com

In 2000, Uncle Bob introduced SOLID, but a lot of code is still being written today that breaks these principles. These principles should be the baseline in terms of design for any enterprise application. Everybody has their own reason for neglecting them, but most of the time short deadlines are to blame. It’s true, we all have faced days when the due date was fast approaching and we still had plenty of work to do. However, this is not something that happens every day, so first, make it work, then keep refactoring until it’s clean.

“You’re not done when it’s working, you’re done when it’s clean!”Robert Martin

The SOLID acronym was introduced by Michael Feathers, author of Working Effectively with Legacy Code, a book that discusses the fear of refactoring.

This sentiment usually appears when we have to deal with legacy code that hasn’t been touched for a long time and areas where we believe we don’t have enough knowledge to start rewriting.

“Legacy code is code without tests.”Michael Feathers

I believe we can have code with a lot of tests that don’t bring much value and if you have strategically important code in your application that you can’t refactor easily that would still be legacy code. 

In 1976, Barry Boehm said that it is more expensive to fix bugs over time and, while there is no research to support this hypothesis, I have noticed that when working with legacy code, without refactoring it and keeping it clean, when an issue shows up it might take a lot of time to provide a proper fix without introducing any other problems.

 

How do we stop the rot?

For a project that has reached a rather high state of degradation, most of the time the solution chosen is to increase the team. However, this might not be the best solution as it just solves the symptoms, not the problem itself, and this only temporarily.

Uncle Bob says that “new people suck the life out of old people for months” because they need training, ramping up and supervising. But more than that, it’s not the “old people” who train the new team members, but rather the legacy code is the one training them.

The solution could be a combination of multiple things:

  • When you’re designing and writing your code take into account the SOLID principles
  • Value testability – Testing helps us create the right design for our applications and accelerate the development process, but at the same time tests can be considered a safety net when we need to make changes.
  • Strive for simplicity – Two sayings that come from the Extreme Programming community are “Do the Simplest Thing That Could Possibly Work” and “You Aren’t Going to Need It.” Following this advice, we reduce complexity and let the software evolve incrementally with small steps.
  • Value code reviews – Code reviews are very important because they check the consistency of the design and implementation. It can help identify potential bugs in that implementation or a colleague can simply give you new ideas from a different perspective.
  • Establish common coding guidelines – If there are no common coding guidelines in a team, it would be a total mess; teamwork would be a kind of Babel tower.
  • Refactor, small and often – The importance of periodic refactoring is also pretty clear because it helps us clean up the code, make it easier to understand or adopt new frameworks or procedures.
  • Make the best use of the tools out there – Nowadays there are plenty of tools that programmers can use to make their life easier. For example, SonarQube, JArchitect, Kritika.io or Klockwork, just in terms of code quality analysis.
  • Document the code – Documentation helps to take into account all aspects of an application and helps a lot to increase quality. It is important to document design changes and decisions whenever possible and as organized and consistent as possible (i.e. using the same format, following some rules).
  • Influence your colleagues – You may not even know the impact you could have on your colleagues. Whenever necessary, try to inspire your teammates with the quality of your code or with feedback that would help them evolve.

Next time you start a new feature, think about the principles, tips and advice from this article. If you want to learn more, read Clean Code by Robert C. Martin and take a look at the UnityCoin YouTube channel where you’ll find a short series regarding this topic.

Background Image