It is well known that applications tend to rot after time (i.e. after changes have been made to them) but, up to this recent feature request, I was unsure of the the actual cause of this rot.
Application rot comes from the chaotic relief of the tension created by changes that induce changes in fundamentals and invariants. This chaotic relief increases the software entropy, as software quality and maintainability principles get violated.
As I was implementing the aforementioned new feature, the tension on the application was causing its design, its thread safeness and its clarity to degrade at a distressing speed. I was going fast, but not. Fortunately, my alarm bell was ringing loud and clear and, after reverting to the latest head revision, I started again with a holistic plan that was taking care of not increasing the entropy of the application.
During this I have noted that nowadays:
- Tools are efficient in helping us keeping the entropy low (FindBugs and Checkstyle were shaking their heads about some bad stuff I was doing),
- Libraries are now rich enough to help mitigating changes that can compromise thread safety (think Java Concurrency or Intel Threading Building Blocks),
- Industry luminaries have preached the need of elevated professional standards enough to make us become conscious of software rot when it happens (the bell goes on).
