A story about technical debt…
I work on an application that tracks millions of requests each day. There was a time when we recycled the application pools of the web servers in the web farm. During this process we lost a few seconds of processing – in which there may be a few thousands requests not tracked. I referred to this in a meeting awhile back as, “fries on the floor.” The analogy made me think about things that matter when they are added up over time.
It reminded me of the typical fast food restaurant. You look behind the counter and what do you see? A few fries on the floor right? Not a big deal. Moving at the speed of fast food and dropping a few fries on the floor is all part of business. But I got to thinking about how many fries (pounds) that adds up to be for a single restaurant, or all restaurants in a single day over a week, month, or year. A few fries on the floor probably add up to tons of wasted french fries. Why am I concerned? I’m not too concerned about the fries, really. But I am concerned with the mentality of waste and letting things build up over time – things that create technical debt.
Using the same analogy to the software development life cycle, we are leaving some fries on the floor or in essence creating some technical debt. We do this on each sprint, cycle, project, new feature added, etc. Business moves pretty fast and most companies that develop their own software or solutions hire the minimum number of developers for the job less one, right? We’re all pretty busy. The problem is that we move on to the next round of features or stories to implement. And of course many of us are eager to do so – doing something new and different is pretty cool; and we are eager to please. But we are creating technical debt. It may not feel like it in the beginning, but over time the debt accumulates and starts to compound. Then we are in trouble. You have to address the debt.
Why not leave a few less fries on the floor each day by doing some or any of the following:
- design first
- thorough business analysis
- peer code reviews (daily)
- refactoring loose code
- test-driven development
- unit testing for a specified amount of code coverage
- alternate flow unit testing (negative tests)
- performance analysis of the new release
- making specific elements configurable vs. hard-coded
- refactoring to a design pattern
- documentation of the feature
- code review by team
- ________________ (add more items here)