One of the most common causes of difficult to maintain software is falling foul of the sunk cost fallacy. When you've put so much time and energy into making something, it can be difficult to open your mind to better alternatives. We often equate more value to the things we build ourselves, even though to others, it may be an inferior solution. Being willing to take a step back and question whether your approach is the right one and be open to alternative solutions is a ultimate power move. Don't be precious about the code you build. It's there to be changed, built upon, or even replaced completely.
Right, getting emotionally attached to what you write can really hurt not only yourself, but the whole team / organization as well. It's really important to understand that the code that we write is here to solve a certain problem. How good we solve the problem -> that's what's really important.
I'm speaking to fellow sufferers of not wanting to delete/abandon your precious code, you can save it for later. It'll live in your Github forever.
I keep seeing this in big organisations, where we spend more time and money maintaining legacy platforms than it would cost to just outright replace them.
Managers seem to be particularly susceptible to the sunk cost fallacy, Jade. 🙄
Any code can be cleaned up. One of the ways I do it is by proving the concepts in another area of the software. A few companies ago I built out the new way as an Admin and Debug tool. But since the Admin had to show all the data which the user facing side would show, it was a short hop to replace everything. A designer was then able to make a new design since we now had this new fangled concept of a "master page" and the entire site looked way prettier without having to modify every single page. It blew the customers away. If you want to build a new tool to prove an easier, cleaner way of doing things, find a small section you can prove it works with. The problem with off the shelf software is that you can become dependent on a third party to fix things and add features you need. The real trick is just getting good at coding and not writing software that is difficult to maintain and extend. And it all starts by having a well designed database.
Ooh. This is one of my favorite conundrums. How do you know when you’re falling afoul of the sunk cost fallacy and not just giving in? Every time I start considering giving up on something I wonder if I just need to have a little more grit and tenacity, or if I’ve already sunk too much energy into it. Where do you draw that line between tenacity and idiocy? Not that you’re an idiot—I’m the idiot in this scenario.
I always tell people that software is meant to solve a problem, it is not your child. If the problem changes, or your understanding of the problem changes, then the solution has to change. It isn’t a personal attack, just a basic response to change.
I personally wish that management would offer to stand up for the developers who have not previously recieved help (a 1 person show that has been asking for someone to mentor for ages) and maintain the operational system, versus a new team with a lot of resources to replace it with something better, but not close to ther opperational capacity.
Context-driven software engineer in test | Scrum master
5d"We often equate more value to the things we build ourselves, even though to others, it may be an inferior solution." In addition to sunk cost fallacy, I've also seen this particular case referred to as "Not Invented Here Syndrome".