The law of entropy is driving the whole universe. The term means that all things strive to chaos and disorder. The molecules of everything are constantly trying to scatter in space. Only an applied external force is keeping all parts arranged and in some kind of order.
So remember the chaos is everywhere around us and everything is trying to achieve it. Our job is to keep it as minimal as possible.
What is software entropy
Unfortunately the same principles are valid for the software development.
Do you remember how did you start your last project? What was the architecture and how was it applied? What classes did you have and how were they communicating with each other? How did the class diagram looked like at the end of the first version of the project?
Hopefully everything was looking smooth, arranged and well done.
What was the situation after version two? Then version three?
How did the project and its components looked like at the end? Did you see the same smoothness, understanding and perfect layering as it was at the beginning? What about the code smells and technical debts?
The software entropy is a great force and tries to push the project to disorder with every iteration, every piece of new code added, every new feature.
It searches for weaknesses in the architecture.
It pushes when there is a tight deadline as well.
Take a look at this example of an initial software design.
There are several layers, clear connections and transparent workflow.
When the project moves on, new functionalities are added and the logical elements are expanding. After several iterations you might end up with the following evolution of your initial design:
The more code the team produces the more complex the software becomes and the more doors can be opened for the entropy to expand.
How to prevent the negative expansion
If you want to hold the entropy as much as you can you should put effort in it.
Invest more time and energy in the initial architecture. Learn the domain as much as you can. Clear all business requirements and discuss them back with the business people in order to be 100% sure you are on the same page. Build the big picture and also dig deeper into the details. Discuss again with the co-workers, architects, BAs, stakeholders, etc. Build up a clear architecture that is aligned with the business requirements. Set up the basic user stories based on the built design.
Follow coding standards. By doing it you are setting a frame and your code will be more consistent, descriptive and correct in terms of standards.
Follow conventions like a naming convention. That way your code will be readable and easy to handle by many people.
Apply design patterns. This step is very important to keep the software entropy away as much as possible. In order not to write a spaghetti code apply an appropriate design pattern. However, keep in mind that every design pattern has its own purpose and use case and should be applied only in case it solves a certain problem. There are many resources for the design patterns, so everyone should be familiar with them. A must read book is the Gang of Four’s Design Patterns.
From time to time stop and observe the big picture. Generate a class diagram and examine the relations between the different objects. Look for the following: encapsulation violations, references which breaks the initial architecture, existence of unneeded layers, not respecting the layers in the applied architecture.
Code reviews are also very useful and important. It is always beneficial for an implementation to be reviewed from someone with another point of view. Every person looks at the world from a different angle, so it is the same with the coding.
Write testable code. Adopt approaches like TDD. Doing so you will frame and define your logic, which will then be covered by the implementation.
Know and apply the acronyms: SOLID, DRY, YAGNI, KISS.
Single Responsibility, Open-Close, Liskov Substitution, Interface segregation and Dependency Inversion Principles are crucial if you are an object oriented language developer. There are plenty of resources describing the SOLID principles with examples and real-world analogues, so browse the net and have fun.
DRY stands for don’t repeat yourself. It is self explanatory – do not repeat code. Achieve it by dividing your system into logical, reusable pieces.
YAGNI is abbreviation from You Aren’t Gonna Need It. That means do not include a code in the project which is not needed for the time being (e.g. you think it will be required in the future). So include only the necessary information and logic. All other pieces of code are actually a liability for the project, the team and the company. There is an article about Your code is a liability, where the author is stating that every line of code is a liability. I can correct it a bit like this – every unneeded (for the moment) line of code is a liability.
KISS stands for Keep It Simple, Stupid, and means to keep your code understandable and clean. Do not over-complicate it. The best code is the simple one. So when you are developing a piece of code think of all alternative solutions and pick wisely.
Refactoring. This is a constant, on-going process through the project’s development. Revision and refactoring will happen for every new thing added inside the existing system. It keeps your code structured and tight. So be vigilant for problems and resolve them accordingly.
The regular refactoring is part of the modern software development process.
A good source about refactoring, design patterns and how to apply them is Refactoring to Patterns by Joshua Kerievsky and Martin Fowler’s Refactoring.
And finally – do not be lazy. Apply all of the best practices, develop yourself and always write a good, quality code to be proud of.