Stop ignoring tech debts (and the Mars astronaut problem)
Frequently while working with software development, you face a piece of code that is not well written, is error prone or may cause performance degradation of the feature you are working on or even the system entirely. If you are a software developer, I’m pretty sure you are familiar with it. These crappy codes we call “Technical Debts”, formally speaking, or “Broken Windows” following Andy Hunt illustration in Pragmatic Programmer. We are used to Broken Windows, we see them everyday, we can recognize them pretty easily, but often we don’t fix them. There is a lot of reasons why we don’t do that: “we risk to not deliver on time”, “this refactoring has no business value and therefore you should work on this story that has the top priority”, “the refactoring will take a lot of work”, etc
But follow me on an example: imagine you are working in a new rocket launcher for NASA (or any other Spacial Agency). You are responsible for the calculation of the right angle the rocket should take off after leaving Earth. You did TDD, all tests well written and accepted, all engineers are happy, therefore, it is ok to deploy to production. The Spacial Agency plans to send 2 people to Mars on a given window of time, when all the universe would be best aligned to a proper launch. Then the rocket with the 2 crazy astronauts take off, and all goes well in the first 2 weeks after the space “ship” left Earth, when you realizes something weird: the ship will miss Mars. “But what went wrong?”, you think! “All tests passed, the engineers confirm the results, everything looks right. I don’t understand”. Then you review all the code, all looks good. Then you took your hand calculator and you do all the math by hand, and compared to the algorithm results. That chills down your spine: your calculations result in an angle of 36°34532923', and plotting it to the space map, would deliver the ship in Mars, but the algorithm resulted in 36°34533', it is rounding the angle to 5 decimal points. Wow! In a travel of light years, as the times goes by, that could send the astronauts to another galaxy.
Ok, it is intentionally a stupid and exaggerated example. But it works to illustrate my view: as the time goes by, it is harder and harder to fix a Technical Debt. If you think about the launcher example, you’ll realize that as the ship gets more and more away from Earth, the distance between the right path and the actual path will increase dramatically. That’s my point here. When we ignore broken windows or let the fix to when we “have free time”, maybe the distance will reach a point that there is no way to fix it, after an entire team put their hands on it, adding more and more complexity. And then you face that it would take too much time and effort to fix, and the client won’t pay that (what makes a lot of sense, since it will not add any business value to the product).
This way, we should stop ignoring your tech debts. We should be able to negotiate the fix with product owners to work on it as soon as possible. Not because we like good code (because of that too, of course), but more importantly, we want to deliver a product that is robust and has a long and happy life. ;)
So, my 2 cents: stop ignoring technical debts, stop ignoring technical debts and more importantly, stop ignoring technical debts.