Mohammad Forouzani

Pay off your technical debt by refactoring regularly

Posted on 18. Aug, 2011 by forouzani in Management, Web Development

Being in a startup often means you take the path of least resistance to get the job done – you have to, it’s one of the advantages you have to being small, you are agile and can get things done fast, something corporates can’t do because of all of their business processes and red tape. But cutting corners can lead to problems – it usually encourages developers to build things the quick and dirty way, just to meet a deadline or beat the competition. This technical debt, which accrues interest in the form of extra effort required for future development work, can be a major burden on a startup technical teams – to the point of losing staff or inviting hackers to compromise your systems.

I have seen startups get multi-million dollar funding for a codebase that is so poor, it could be compromised within minutes, and requires a complete overhaul to allow for further scaling. If only the investors knew what they were investing in. (of course the value of a business is a lot more than just their codebase, but when dealing with a strictly online web based business, the codebase is a principle asset)

The truth is that there is no way to have a perfect codebase at all times. Technical debt is necessary in any sizable project, the key is to make sure it is managed and contained within a reasonable level. The point here is that to maintain a high ROI, it’s ok to have some technical debt – refactoring every week is an unreasonable expectation. But there is always a point where the interest being paid on your technical debt is enormous – at this stage you need to refactor significantly to continue scaling the project. This should be considered an architectural (and possibly an infrastructure) change, something that may not have an immediate ROI, but will accelerate development in the future.

As technology evolves, and a project grows, and best practices change, and new technologies spring up that can solve problems more efficiently – refactoring and re-architecting becomes mandatory, but its not about eliminating technical debt, its just about finding the right balance of debt required to maximize ROI. This balance point, is usually obtained through close collaboration with the team leads and architects.

Tags: refactoring, scaling, technical debt