Entropy is the law that governs processes that we consider irreversible, but not because there is a physical force that forces the particles to behave in that way; but because it is the most likely to happen.
We can use this definition to implement an analogy in our day-to-day activity, which is writing code. Systems tend to get more complex with every piece of code we write, this is code that needs to be maintained and that is going to interact with more code that will be written in the future.
When structural engineers are designing a building they take thorough care of every single detail of the structure, they want to get the perfect balance of rigidity, elasticity, and cost. They run a bunch of simulations to make sure the structure will uphold against the external forces caused by the events of nature, they know the behavior of the internal forces that are interacting at any point of the structure, they have complete control of the system, they don't allow to be entropy.
We can have that level of control too, to achieve it we have to be as conscious of every single detail of our system as a structural engineer is of their structure.
How can we keep control of the entropy?
The answer is simple; unit testing, clean code, and design patterns. That's it! The problem is that it's too easy to don't do any of that stuff because at the end of the day we are delivering our users what they want, right?. They don't care about the internal parts of the software they are using, they just want it to work seamlessly.
But what about our colleagues? What about the quality of our work? What about our craft?
Yes, we are delivering software that works but in a state that we are scared to touch it, we even get to hate to work on those systems, we all have gone through that and the worst part of it is that we just keep adding to the mess instead of taking control of it, we keep contributing to the entropy of the code. The good news is that it is possible to change that behavior, to control the entropy of the system we need to be conscious of it at all times, whenever we are making changes to the code or adding new code, we have to follow certain rules to don't allow it to get in a greater state of disorder.
These rules have been very well documented and are available to everyone that wants to write good quality software, just go with the classics, these are pieces of information that have survived through the rapid changes of technology and still are very valuable, the books that I'm talking about are:
- Clean Code, Robert Martin
- Refactoring: Improving the Design of Existing Code, Martin Fowler
- Working Effectively with Legacy Code, Michael C. Feathers
- Design Patterns: Elements of Reusable Object-Oriented Software, Eric Gamma
- Test-driven development by example, Kent Beck
I'm not saying to just read them once and forget about them, I encourage you to have them close whenever you are writing code, use them as reference books.
If you are refactoring a class, writing a new function or test, naming a variable, whatever you may be doing, be always conscious of it, don't allow your code to be part of the mess instead make it to be part of the order. Don't deliver "something that works" and move on, try to always deliver something that you are proud of, because it is your work, it is your craft that we are talking about.
Top comments (0)