My colleague Matt Heusser will be hosting a peer conference on "technical debt" later in the summer. I've been thinking about the subject and realized that technical debt could be interpreted as a kind of impedance mismatch. Impedance mismatch happens in acoustics, electric current, and many other places. Here are a couple of examples that everyone will understand:
trying to fill a swimming pool with an eye dropper
trying to get a drop of water from a firehose
I can think of two software examples from my own career, one involving tools, the other involving skill.
An application I was testing the other day has two javascript prompts in a row. Selenium correctly recognized and dismissed the first prompt, but it is not able to see or manipulate the second one. As a result, I have an unfinished automated test, and technical debt in the form of selenium hacking, manual testing, and future test maintenance. This is the eyedropper-swimming-pool example: no matter how much effort I expend, there is no way I can overcome the nature of the problem at hand. I'm forced to improve my tools in order to overcome technical debt.
In my career I have been a tester on two different COBOL systems. One was very nicely designed and maintained, the other was a total nightmare. The developers of the nightmare system were very poor coders. COBOL makes it easy to do dumb things, and the codebase was full of dumb things from people who didn't know any better. This is the water-drop-from-a-firehose problem: gross efforts were accepted when fine manipulation was required. The developers have to improve their skills in order to overcome technical debt.
If this really is a valid comparison, it might even be measurable in the way that electric current and sound pressure levels are measurable. If not, it is still worth noting that having the appropriate tools and the appropriate level of skill in the project team will likely minimize technical debt.
trying to fill a swimming pool with an eye dropper
trying to get a drop of water from a firehose
I can think of two software examples from my own career, one involving tools, the other involving skill.
An application I was testing the other day has two javascript prompts in a row. Selenium correctly recognized and dismissed the first prompt, but it is not able to see or manipulate the second one. As a result, I have an unfinished automated test, and technical debt in the form of selenium hacking, manual testing, and future test maintenance. This is the eyedropper-swimming-pool example: no matter how much effort I expend, there is no way I can overcome the nature of the problem at hand. I'm forced to improve my tools in order to overcome technical debt.
In my career I have been a tester on two different COBOL systems. One was very nicely designed and maintained, the other was a total nightmare. The developers of the nightmare system were very poor coders. COBOL makes it easy to do dumb things, and the codebase was full of dumb things from people who didn't know any better. This is the water-drop-from-a-firehose problem: gross efforts were accepted when fine manipulation was required. The developers have to improve their skills in order to overcome technical debt.
If this really is a valid comparison, it might even be measurable in the way that electric current and sound pressure levels are measurable. If not, it is still worth noting that having the appropriate tools and the appropriate level of skill in the project team will likely minimize technical debt.