I’ve referenced this concept so many times in the past but have never put my thoughts down on paper – also please read the quote at the bottom of the post as it is another excellent representation of this concept.
My perspective that I always like give is becoming comfortable/complacent with how things are in your job or the application that you’re actively coding.
At the start, when you become a developer on a legacy application, you absolutely hate it and it’s lack of clear/concise documentation – not to mention it’s spaghetti/house-of-cards codebase.
Over time, you learn to appreciate and sympathize with it’s design paradigms despite your initial reaction that it was (and still is) a dumpster fire – hence the “Stockholm Syndrome of Software” idea.
This is how I feel about Google Cloud and Amazon AWS most of the time with how disorganized, non-documented, and confusing they are – among a few applications I’ve had to work on in my career.
I’ve linked people this quote below I agree with so many times that I realized that it’s potentially going to 404 one day and I wanted to go ahead and save it for future coding generations.
I’ve talked about how customers get so attached to failed code, trying to save some form of cost from a failed software project and unwilling to part with the disaster, that I’ve come up with a term for it. I refer to it as the “Stockholm Syndrome of Software.” The basic idea is that customers get so attached to failed software projects, they will try to do anything to save the investment, including trying to sprinkle a new software project with failed pieces of software.
It is understandable. On the surface, this makes sense. Surely somewhere in this pile of code, there is something that it makes sense to keep. Or, another view of it is that we, the company, can just throw out the old developers, bring some newer/better developers in to solve our problems. These new developers, all they need to do is to cut the head off of a live chicken, perform a voodoo dance around a keyboard, presto changeo, and we have a fully running system.
This is a nightmare. The code failed for a reason. If the previous set of developers didn’t know what they were doing, why do you think the architecture that they started is worth a damn? Why run on top of the old software? Why would you want to infect good code with bad?
Sorry folks, software that doesn’t work and never reached the level of being acceptable for use by being deployed is not really suitable for use. Instead of spending good money on top of bad and trying to keep software on life support that should be shot, go ahead and admit that the software is a sunk cost. Throw the non working code away. Get a set of developers that are trustworthy and can deliver. Don’t micromanage them. Don’t tell them to just put a few tweaks on the non working code. Don’t cling to the old code, trust me, you will be better off.
I find that this problem is rampant. Everyone thinks that they can save a few bucks by going the cheap route. The cheap route doesn’t tend to work. The cheap route costs more with software that doesn’t quite work. It fails in weird places. It craps out with 5 users. It does all the wrong stuff at the wrong time. Trust me, you are better off without cheap, crappy code. Let it go, and do it right.
– Wallace B. McClure, April 9, 2018
https://weblogs.asp.net/wallym/stockholm-syndrome-of-software
Cody's Blog 