| My example of horrible technical debt goes like so: I (not that long ago) worked at a company that kept all their data in MySQL. Sounds fine. The bad part was all their user-facing stuff was written in Microsoft Access. This didn't make any sense and was the main thing that prevented them from moving to a web-based or API-based interface. They had written some code here and there that would cobble a few things together but it wasn't the right way to do it. During a discussion, I asked why there were 2 MySQL servers. They held different databases, but it would have made more sense to have them both on one server. I assumed that at some point in the company history, the data got too big to fit on one server, so they split it up, and that ended up being true. And ever since they had some misguided sense of safety having two different databases, even though if you were missing the other, all functionality would break. At the current time, the databases weren't large enough or accessed enough to require being on separate hardware. It seemed simple enough to just import one into the other and then get on with modernizing the rest of the code. "We would have to re-write the entire codebase since it's based on having two servers" Access lets you basically do joins etc on two separate databases. So this was used heavily. Whenever they tried to duplicate this functionality in PHP or whatever they would try, it turned into a nightmare. I would imagine if they had spent another $10k on hardware back when they first had this problem they would have saved a lot of future troubles. Imagine running legacy versions of Visual Basic, developers needing Windows XP VM's, end users needing two copies of Microsoft Access installed... |