Software Entropy has teeth and eats rot

Every software project starts off with excitement and determination to get it right. We want to build on past successes and failures, but as time moves on, the decisions we make affect the quality and lifetime of the project. We want to improve our skills and we want to create something wonderful, but is your project focused on the important things? In time, your code will become brittle and it will fail. When it begins to fail without you touching your code, this is when the monster named Entropy breaks from its egg and opens his empty eyes. "Feed Me!". Your code can remain the same, untouched, but it begins to fail and strange things happen. This is Entropy, this is rot and your software is becoming brittle.

Feeding entropy is easy. It likes software rot and over years rot can grow and the result could be a rewrite. Let's look at what rot is and how it affects you.

Software Rot

Rot is caused by many factors and Entropy thrives on it. You can create the conditions for rot intentionally or unintentionally depending on your everyday decisions.

• The language and platform you choose
• The dependencies you decide on
• The development environment you use

A classic example of seeing rot is by opening an older project.

If you have 10 or more years experience you will know this well. Open an app from 10 years ago, compile it and run it. How much effort did it take? Does it run the first time? Does it run at all? Is the language is dead?

The platform, language and the dependencies you build on are very important to the potential for future failure. Just ask developers of Visual Basic, Pascal or Adobe Flash/Air.

Platforms at risk include VB.NET, Perl and Ruby? Disagree?

The fight against rot

• Remove dead code. Don't let it stop a build or worse.
• Code against native code first. Use built-in stuff first.
• Don't code against fashionable dependencies
• Code against your interfaces and not on the dependencies (abstractions)
• Remove unused features (especially if they have dependencies)
• Refactor out dependencies (see dependency cleanup)
• Specify and control the Run-time environment

Dependency Cleanup

Over time, some dependencies are not required, because what they offered to you has been absorbed into the platform. Perhaps you could not upload a file easily showing a progress bar, because of the browser being a little naive, so you used a 3rd party component to make life a little easier. Two years later, the browser has improved. Do you still need the old upload component?

Dependencies are also neglected and not updated, while your project continues to grow. If this is the case, replace your dead-end dependency with another that offers the same value but still is in development.

Some dependencies are there but unused, removing them is simple.

Some features of the software seemed like a good idea and look good in demos and on the feature list, but with a quick enquiry, you can discover it is an unused feature. Unnecessary feature complexity and missing your user's real requirements can grow dependencies. Cut back, reduce, simplify and ensure your features are truly helpful, useful and in active use.

The greatest platform gotchas: beware

Platforms, or layers on which you build, compile against, sit on, depend on, are easily the cause of rot. Just because it's not in your code, doesn't mean it won't affect you. For example, integration tools, build tools, platform environments, cloud products and so on. You have to look at all aspects of your development, including IDE's to Deployment. Every technology you use is susceptible to rot.

Sometimes it is the providers' fault and not yours. Microsoft just created a huge amount of rot in hundreds of thousands of projects by splitting and refactoring the .NET Framework into .NET Standard and .NET Core. We now have more complexity in selecting dependencies, a legacy platform within an existing platform, a new platform to think about, a split in the roadmap and of course more complexities in the IDE, deployment and choices you make. It affects every .NET project built. Your .NET project

Manage Business Influence wisely

• Business may want the marketing that can come from a technology. A buzz tech may offer great marketing opportunities, and having your platform sit on top of x, may be very attractive.
• Business may want features because they feel it will drive sales
• Business may want a partnership with a provider and insist on a dependency be integrated. This may be an API integration or a platform.

Business is focused on acquisition and sales, and often cost of software and effort of the development is secondary. As a designer, architect or product owner, you have to be able to negotiate the balance between decisions that will cause rot, and the features that won't.

If you cannot influence the decision, your code must not falter to maintain the fight against rot. You have a really hard decision if it's a complete platform, as your code and the platform will be fatefully intertwined. Your code will become completely dependent on the platform and very little code will survive after the death of the platform. A rewrite will be your only option.

In other cases, you can manage the feature with design patterns and good architecture. Ensure the API you are calling is abstracted away and you can rely on yourself more than the 3rd party. You can secure this kind of design with DependencyInjection, Interfaces, dynamic or loose-coupling mechanisms.

Does this apply to my project?

This is not scientifically backed up, I have no studies to show you and it's purely based on my experience. But the question is, is your project at risk?

How much rot does your software already have? It's not purely based on the age of the project, but it does have a linear increase over time. Here are my lists for understanding rot risk in code.

Time

• 1-2 years - Low Risk
• 3-6 years - Medium Risk
• 7-10 years - High Risk

Team Size

• 1-4 - High Risk
• 5-10 - Medium Risk
• 11+ - Low Risk

Combined Team Experience

• 1-20 Years - High Risk
• 21-40 Years - Medium Risk
• 41+ years - Low Risk

Team Type

• With Designer/Architect - Low Risk
• Without Designer/Architect - Medium Risk

Platform Age

• 1-8 years - High Risk
• 8+ years - Medium Risk

Conclusion

Actively staving off software rot, has to become part of your toolbox. You need to think about each feature, each business driver, each dependency you include, each line of code you use or don't use. You have to think about roadmaps for each technology, the platforms you build on, the smallest plugin you use. You have to beat rot back with a stick, or it will eat your resources, your time and the business that the software depends on will suffer greatly.