Technical Debt In Its Simplest Form

Today I had some „fun“ with a set of API test automation scripts, failing, because the developer allegedly fixed a typo in the web service interface. Presumably the typo must have been there right from the start and was for logical reasons mirrored in the http requests of my test scripts. As it happens, lately a new version has been deployed into the test instance, including the „fixed“ typo and therefore providing this new interface for one single API operation.

As a result all tests failed. Good tests BTW. Just think about client apps using this web service without any update regarding the „fix“.

I then analyzed the results and quickly found the bug in my script (an error message told me about a missing parameter value). That’s what I thought. But soon I got sceptical. I knew the tests had already run for a long time, succsessfully providing informations about the SUT and I never observed a behaviour like this before. Soon I came to the conlusion someone must have fixed this typo again:

From < jrp:artnumebr > to < jrp:artnumber >. A simple fix for the developer. With great power comes great responsibility.

And I was right.
That’s technical debt. Such a typo isn’t easy to fix as there are a lot of dependencies, a lot of services and applications make use of this operation, already coded with this typo. This should have been fixed right at the very beginning. Now it’s not so easy anymore.