The Value of Long-Range Vision - Testing

Posted by: David Kleinschmidt 10 years, 2 months ago

(An example of how skimping on testing can cause forward progress on a software system to slow and eventually stop. This story is from real events, but people's names and organizations have been changed or anonymized.)

Back in the early days of the Internet, a major company with a successful brick-and-morter business model decided to branch into online sales and product delivery. They hired a technology team with developers, administrators, and a quality assurance team to create their online presence, along with content creators to define what the technology team was responsible for doing. They built up a successful business, bought out several competitors, consolidated control over the online version of their industry, and maintained steady growth for a decade.

There was only one problem: As the company came up with new great ideas and products to add to their online business, the technology team was apparently slowing down. Tasks which seemed like they could be done in a matter of a few minutes would take hours, week-long projects quickly became month-long projects, and meanwhile the business was stagnating. Project managers attempted to address the problem, with numerous theories:

Was the tech team just lazy? This didn't seem likely - they were arriving for work on time and often staying late into the night, and yelling at them to work harder or longer didn't seem to help.
Were projects ill-defined? The project managers worked hard to make sure all requirements were crystal-clear, and the tech team seemed to be comfortable asking questions when they ran into confusion.
Was there an estimation problem? They created a process for estimates to be gathered from the development team prior to the project, but those estimates still seemed far too long for simple tasks.

Still searching for clues, the management team demanded that the technical team to track what they were spending their time doing, and promptly discovered the real problem: Well over half of their time was going not to the new projects that the rest of the company had decided were worth doing, but instead was devoted to keeping the existing systems from falling apart. Even a seemingly small change to the system required hours of testing and fixing underlying problems. And while the rest of the company was frustrated by the slow progress, the only solution offered by the technical team would make their latest projects even slower by allowing the tech team to allocate some of their time to redoing portions of the existing system each month. This was intolerable, because it would jeopardize the quarterly and annual goals that each business team was trying to meet.

Growth in the online business, once a driver of the company, stagnated, and the upper management decided to fold the online division back into the rest of the organization, having never really fulfilled the goals of the company.

This problem is hardly limited to a single company. Experienced software engineer Ward Cunningham coined the term "Technical Debt" to describe the effect of past decisions and poor testing slowing your organization's forward progress down to the point where most of your time is spent managing the consequences of past decisions rather than creating new products or services.

Erie Eyrie Software plans ahead to avoid this phenomenon by working with small organized pieces that are thoroughly tested and documented, so that we can easily adjust the system when business needs change. Our use of Agile methodology makes design improvements and increased flexibility part of any change we make, while maintaining a usable system throughout the process so that your organization can continue to operate without interruption.