Technical Debt is not simply an Agile buzzword more than it is a fact of software development. Just like any other debt it imposes negative ramifications on the software and significant loss is revenue.
I hate to get touchy feely but I think what I am about to say holds the most weight when presented in this manner.
If we look at our code as a living and breathing life form, we are responsible for its creation and well being. As we hack through our code feverishly because of dead lines or time constraints we severely retard the health of our code. Why do we allow this to happen? Usually this is because we don’t have anything to monitor the cholesterol or blood sugar level of the code. There is no external indicators that allow us to gauge the health of the code.
Take for instance when I was in high school I use to love to play sports, any sport. If it had a ball in it, I was there. My mother told me to watch what I ate, make sure to eat lots of vegetables , exercise, etc. Did I listen???? No! I ate what ever I wanted and didn’t give it any thought because there wasn’t any immediate external visible signs of what was happening to me internally. I could leap, run and jump with the same intensity as I did when I was a child so why should I change?
Now fast forward 20 years. Well, I still love to play sports but I can’t play them near the same intensity I had as a teenager. My body hurts in places I never even knew could hurt. Jumping down off the kitchen counter causes my knees to buckle under the pressure of descending 3 feet! What I didn’t know is that I was incurring a health debt early on in my child hood that is having horrible compounding effects in my middle age.
The same deteriorating effects happen with software, just at a much more rapid pace. This deterioration happens in front of our noses, we just don’t pay it any attention because there isn’t any external indication of the impact to health of our software. Or is there?
- Can you change your code and understand the side effect or worse are you afraid to change your code at all?
- Can you *easily* change your code or do you spend sleepless nights adding the simplest of changes to your code?
- Do you know how much of your code is tightly coupled?
- Do you think that orthogonal principles are something that is only for enterprise projects?
- When you run a code coverage tool do you throw the results away because there is so much red and not enough time?
- Are you prioritizing defects as Critical, Important, High, Medium and Low; where Important and High account for 80% of the defects but are not taken care of because they are not in a critical state?
- Do you follow ANY type of SDLC?
- Do you attempt to include your customer or at least have a customer proxy to advocate concern and prioritize your work?
- Is your code littered with comments such as, “we need to fix this”, “Don’t change this because I don’t know how I fixed this?”, “WTF?”
Now the magnitude of how much each one of these questions effects technical debt is purely subjective. The point I am trying to make is that your code is not in a healthy state and has the possibility of contracting a terminal illness that will lead to its death if you don’t take care of it now!