KISS for Reducing Tech Debt
Instead of getting wrapped up in the minutia of software development, sometimes it's more beneficial to just keep it simple, stupid.
Join the DZone community and get the full member experience.Join For Free
Tech debt is a major concern for dev teams. The word "Debt" implies its effect on planning and the cost of maintaining a product, as well as its impacts on company reputation and developers' morale. There are multiple reasons for tech debts. Let's see how the KISS (Keep It Simple, Stupid) principle can help reduce tech debt.
This is part of development; the trick is how we look at solving a problem. Generally, before starting development, we tend to think too much about finding the best of the design patterns, technology, framework, software development philosophies. These are essential, but not to be discussed every time. Find a simple solution and a simpler implementation. Creating a lot of interfaces, abstractions, factories, and generic codes with the intent to create shared libraries will add overhead for development. These things need to be built as platforms. For product development, the focus should be on product features.
If we try to design a microservice as a layered architecture and create domains, builders, and factories, we are adding unwanted complexity. Excess complexity lead to hurried development, pushing things for the future, eventually creating tech debt.
Use of Non-Standard Libraries
Learning while you work is a general principle adopted for skills development. It is bad for products. We are amazed by new technologies evolving in the market, so we try to learn it, implement it, and experiment with it. But product development is not the place for it. These are good when we are setting up things as a new company, but as the company grows, we need standardization. Standardization creates a common language that everyone the in company understands. Products built with non-standard stacks are hard to maintain, and become vulnerable. Cleaning up these dependencies adds to tech debt. A simple way is to align to a standard stack. But never hesitate to work with teams to contribute for enriching standard stack.
No End-of-Life Plan for Products
Due to upgrades in a standard software stack and changing business needs, we should stop enhancing and start thinking about decommissioning. Enhancing the same product for multiple years results in bulky software with obsolete and unused features. These dead features pose a risk for new features. A simple way is to deprecate features by defining the EOL version, removing unwanted features, all while we build new enhancements to keep the software lighter. Another approach would be to take useful things out from the old product, build a new one, and decommission the old product.
Tightly-coupled software components area hard nut to crack. Agile development is all about building things in an iterative way. Every feature added should be self-contained and atomic in nature, which can be turned on/off easily. Loose coupling makes things simpler to evolve, maintain, and decommission.
Habit of Pushing Things to Backlog
As the complexity of software increases, we tend to push things to the future, building a huge backlog of tech debt. To keep things simpler, build what is necessary. Futuristic thinking is good, but it comes with complexity. Don't plan for it unless you're absolutely sure to pick it up in future. In the hope of the future, we complicate things that are being built now. It is easier to modify simple things than coming up with a highly flexible framework to accommodate future requirements.
Opinions expressed by DZone contributors are their own.