How your software can harm the business it once helped build

These days I’m fortunate enough to closely see a business struggle with technical debt.

When this business started, it couldn’t afford to hire very experienced developers, so went for what talent it could find (that’s the politically correct version of “code monkeys”). As the developers jammed their fingers onto the keyboard night and day, the software was able to serve initial clients successfully. The revenue soared, and so did the team.

Fast forward ten years into the future. That legacy code base still delivers good business value, but has become like a giant steel ball tied to the business’s feet:

  • In the absence of unit testing, the team has no confidence that introducing a new feature won’t break an existing one.
  • The developers are forced to be highly unproductive, spending over 50% of their time battling obtuse logic, singular lack of documentation, and correcting bugs that appear out of nowhere.
  • The QA team is working like donkeys, having to run the same tests over and over again to ensure the past and present bugs are handled.
  • Overall morale among developers is low. While the old ones think the code’s working is “obvious”, the new ones comparing it to cleaning horse manure, and want to get out as soon as possible.
  • When a customer raises a complaint, the resolution takes many times longer because nobody is sure how to reproduce the bug.

My point? If you are a business owner, don’t think you’re too smart. Running a software-driven organization takes more than solving “time and work” problems. In software, long-term planning is more important than anywhere else. If your code base is not modular, well tested and 100% documented, you will soon be playing the game of diminishing returns.

Leave a Reply

Your email address will not be published. Required fields are marked *