A lot of tech debt is created because of an unwillingness to throw things out.
Well-run tech teams can build great software, but rarely does this happen on the first try. Proof-of-concepts (POCs), prototypes, and even early releases of applications often prioritize speed over maintainability. They’re filled with learning opportunities — decisions made with less time or knowledge than your team has now, and ways of doing things that you could now do better, if you started over today.
Even more mature software and applications have lots of room to improve. Ask a developer on any team, and they’ll likely be able to point out some part of their product that could benefit from being made more maintainable, or some dead code that needs cleaning up, if only they had the time.
At every stage of a software product, there arises an opportunity to take things away, resulting in tangible improvements to the code base — and consequently improving the product, along with developers’ experiences. Here’s the case for throwing things out.
Call it a First Draft
Software is a competitive industry, and many teams feel pressured to produce high-fidelity, feature-rich applications, even for POCs. Few teams follow a more rigid prototyping process, and may think it a waste of time and developer effort to “redo” an initial version. On the contrary, creating and throwing out an initial prototype can save untold development hours spent on technical debt in the future.
Prototypes, even first versions, are rarely created with long-term maintainability in mind. Often, such a goal would be impossible — the early development process inherently allows developers to explore, answer questions, and research better ways of building. The discoveries that enable long-term maintainability occur while this first version is being built. You can’t put the cart before the horse.
The next time your team creates a POC or v1.0.0, have a retrospective meeting. Ask developers, “If you could start over, what would you build differently? If someone new joined our team, what part of the product would be hardest for them to understand?” While the answers may not necessitate a scorched-earth rebuild, now is the time to be open to throwing out major parts of the codebase that threaten tech debt and future problems with maintainability. If it makes sense to rebuild, rebuild sooner than later. It’s an investment in the future of your team.
Your Customer Tells You What You’re Selling
Customer feedback is a vital component of a successful software product. The sooner you can get it, and the more you can get, the better.
If possible, show early versions of your software to customers. Take advantage of proper user interface evaluations with real users if you have the resources, and if not, at least attempt to garner user input through reviews, surveys, and forums or social media. Young products may discover that the parts or features the customers like best or want most aren’t the next items in your roadmap. Now is the most opportune time to throw out those initial plans and listen to your users.
Begrudgingly admitting later on that you should have pivoted sooner risks producing a sub-par product. You’ll need to look for ways to bolt-on the functionality that customers desire, possibly creating more tech debt in the process, instead of having a more purpose-built application overall.
Delete Dead Code
As software matures and applications grow, teams iterate to incrementally improve parts of the code base. Very often, code that is no longer used remains in the code base, sometimes relocated into an “old” directory, or worse yet, left alone without so much more than a comment to indicate its deprecation.
Dead code bloats your code base, which for growing software products, can translate to more time spent on I/O — everywhere from developers that pull code to their local machines, to CI/CD automation that clones your code base multiple times per day in order to run. If you use hosted cloud services, that extra unused code could be translating into higher costs for storage, I/O, and memory use.
Dead code also confuses developers. Out-of-use files, similar in name or appearance to in-use ones, easily trip up your team members when snippets appear in search tools or an effort to find-and-replace. New team members aren’t prevented from reading these files either, and an eager eye may miss the one-line comment that denotes a file as deprecated. Keeping dead code around costs time, money, and cognitive effort — for no good reason at all.
If you use version control (and if you don’t, we’ve got other things to talk about first…) there’s no excuse for leaving dead code hanging about. Delete unused files, configurations, and outdated docs to save resources and prevent confusion.
Take it to work today:
Be prepared to throw out early versions. Lessons learned from early development are valuable. You can use them to their full potential by being open to doing things differently at an early stage.
Get feedback to find out what you’re selling. Listen to customers and what they want, taking advantage of proper product evaluations if possible. Let this drive your roadmap, and toss items that customers don’t highly value.
Delete dead code. Avoid unnecessary cost, cognitive effort, and wasted time by taking a strict stance against keeping unused code around.