How "Technical Debt" Stops Growth: Planning For Scalability
Monday July 15, 2013
About Graeme Caldwell — Graeme works as an inbound marketer for InterWorx, a revolutionary web hosting control panel for hosts who need scalability and reliability. Follow InterWorx on Twitter at @interworx, Like them on Facebook and check out their blog, http://www.interworx.com/community.
If we accept that all businesses, when creating an infrastructure to support their online presence, should plan with scalability in mind, the question arises as to why so many of them have trouble when the time comes to grow significantly beyond their initial size, especially in those cases where the growth curve is more of a hockey stick than a gentle upward trend.
One would think that all businesses want to grow and know that they want to grow from the very start, but, frequently, expected growth spurts are not smoothly dealt with even when planned for. We’re going to look at a one of the factors that contributes considerably to online businesses growing pains: technical debt, before taking a look at how it produces a situation that stymies scalability and can cost serious money.
Technical debt is a term that’s often used in development. It denotes a situation where solutions to problems in the short term end up causing difficulties with meeting long term goals because those short term solutions have to be unpicked and fixed before moving forward.
Within software development and system administration, solutions are often implemented that aren’t considered best practices. Wider business needs such as the desire to release on time, or ignorance of the possibility of technical debt and lack of understanding of how processes should be properly implemented lead to kludgy and ill-considered solutions that work for the moment but cause a headache in the future.
Technical debt is essentially the extra work that bad decisions in the past impose on present plans. In some cases, the technical debt is so large that the value created by any further development is insufficient to make up for it, and it’s less expensive to simply start again.
The same principle applies to infrastructure deployment, particularly when it comes to decisions regarding planning for horizontal vs. vertical scaling. Planning for vertical scaling often implies making a large technology investment in very expensive servers which have an inherent scalability limit.
Technical Debt And Scalability
In the beginning, any business has a series of problems to solve. There may not be a huge amount of money available, the business must be agile and able to quickly overcome obstacles, system administrators are often under significant pressure from project managers and non-technical founders and executives to “just fix it”, and infrastructure and development costs must be balanced with concrete ROI. The anarchic “we’ll do it properly tomorrow” attitude for getting a business off the ground may be effective in the short term, but it can also leave businesses with a technical debt that prevents them from smoothly moving to the next level.
We’ve talked before about horizontal vs. vertical scaling, and how in many cases horizontal scaling is more appropriate for future-proofing a business against the hoped-for growth spurts. Horizontal scaling can introduce complexity, which always incurs some sort of cost, either in added networking infrastructure or in staff costs, but other routes, while potentially simpler in the short term, can introduce a technical debt which limits growth.
The powerful, vertically expandable servers that a startup invests its seed money in can become a millstone of technical debt that will have to be paid off eventually, whereas clusters built with lower price commodity hardware can be simply scaled by adding more of the same. Horizontal scaling with clusters of inexpensive servers helps to avoid the technical debt that will have to be paid off in the future, often at the cost of inhibiting other business goals.