I previously worked at a company, let’s call it “Edutech” to protect the innocent, that had developed a variety of customer-facing web applications to open their financial information to colleges around the country. The data-center manager, a friend of mine, once told me that they had spent over a million dollars on hardware (machines, SAN, etc) scaling one of our web apps. This application only had to support around 250 concurrent users. I was shocked. Edutech went years without load testing this particular application, even though it was under constant development.
The compounded effect of years of quick and dirty development decisions meant scaling the application in its current form wasn’t possible without the costliest cutting-edge hardware. Previous development decisions had locked the app into approaches that worked effectively only at small scale. Fortunately for Edutech, the function the app provided was so valuable that throwing money and hardware at it was a viable strategy. Load testing was being introduced, as a practice, for the first time at this company that year, because the costs of scaling the application had finally pushed the needle to a point where upper management took note.
Testing is a crucial step in the software development cycle, yet it’s often given short shrift.
Technical debt, a concept proposed by Ward Cunningham, suggests that, like financial debt, a price must be paid later when quick and dirty decisions are made in the development process.
The danger occurs when the debt is not repaid. Every minute spent on not-quite-right code counts as interest on that debt. Entire engineering organizations can be brought to a stand-still under the debt load of an unconsolidated implementation, object oriented or otherwise.
When load testing is a part of your release process, you escape the compounding interest of technical debt. The moral is: test early, and test often.
![[Post to Twitter]](http://www.testomatix.com/blog/wp-content/plugins/tweet-this/icons/tt-twitter.png){kind=icon}