Massive players like Google can afford to let a small bug or two sit in their code for years, but what about everybody else? Andrew Cohen understands in an article for Entrepreneur that the ability to spot and eliminate technical debt can make all the difference for long-term product success. He devises six steps for keeping debt at bay:
- Don’t open too many cans of worms.
- Consider an early code refactor.
- Hire the right CTO.
- Do some things the hard way.
- Minimize developer turnover.
- Create team redundancies.
We Must Protect This House
When it comes to adding new features, knowing how much time it will take to build them is not enough. You also need to know how much new ongoing work will be created to maintain them, so that you can decide whether it is truly cost-effective to open a new can of worms with a new feature. In cases where a product has undergone many structural changes over time, the code can start to look like a wall with chipping paint, where unrelated designs stand side-by-side and are disconcerting to people who are not used to them. If your code suffers from peeling wall, consider a refactor to clean it up and weed out any strangeness, especially if you are planning to scale up.
Hiring a CTO who has a couple years’ experience in products dealing with code lines numbering in the hundreds of thousands will be a great boon as well. This is the sort of person who will be most capable at helping to scale your products. Still, sometimes things need to get done the “hard way,” as Cohen says:
The right engineer…considers the complete long-term implications of each feature… The right engineer understands the proper tradeoffs between development speed, performance, scalability, stability, security, reliability and maintainability. The right engineer may initially take twice as long to develop a feature to avoid the risk that it takes 10 times as long to rewrite later. This skill of knowing where to draw the line only comes with experience.
Being able to find and keep the high-level talent is a step in itself to overcoming technical debt. It takes considerable time and resources to help a new developer get over the learning curve of legacy code, so it is much preferable to just keep the developers you already have excited to stick around. But since you cannot chain employees to a desk, do the next best thing and build in team redundancy. At least two people should understand any given aspect of the code base; just make sure none of those pairs ever travel on the same plane!
You can read the original article here: http://www.entrepreneur.com/article/244390