One of the hardest things to do as a developer is to throw away a large block of code because, despite all the invested time and effort, the results just aren't good enough. This is where I am with one of my work projects despite the dozens of hours invested as it's become a massive time sink with zero appreciable benefits going forward. Yes, with time, I could work through a lot of the issues one by one … but this isn't what I'm being paid to do. My responsibilities involve getting things done, not tinkering about with browser-related edge cases to paper over past decisions. So, regardless of the effort invested, I'm going to throw the code away and approach the problem from a different angle.
Back in the mid-2000s, a year or so before this blog was started, I was working on a project at a printing company that aimed to reduce the amount of paperwork pressmen needed to do during their regular workday. As with most corporate projects, the requirements were incredibly complex and seemed to change with every phase of the moon. The codebase started to become increasingly bloated with business rules that would stand in the way of getting work done and, worst of all, the application was starting to consume far too many resources while running1. The PCs at the printing presses would occasionally crash or freeze as a result of the software, which resulted in lost data. Nobody was happy about this.
So, being young, single, and stupid, I decided to invest an entire long weekend into fixing the application. Three entire days were spent at home, in front of the computer, working on solving resource problems through various means. On the first day back I went immediately to the printing plant and updated the application to the latest build. Five minutes into testing, the system showed signs of struggle. Ten minutes in, the computer locked up and blue screened. There was just too much data coming in from the printing press and too many business rules that needed to be run with each operation. Despite working the entire weekend, stopping only for coffee, food, and the bathroom, the problem persisted.
Suffice it to say, nobody was happy about this.
Later that morning I asked a senior colleague to take a look at the code. Within 20 minutes he pointed out a number of areas that could be improved with huge swaths of code being outright deleted. I'll never forget what he said:
You've got recent code reversing out past code just for the sake of holding on to the work you did a few days ago? Don't do that!
He was right, of course. I don't remember why I did what I did, but I remember how I solved the performance problems: I rewrote the program from scratch, using two working days and two nights to get it done. Thursday morning I went straight to the printing plant, updated the application, and watched.
Everything worked as expected. There were a few bugs here and there, of course, but the core application was receiving data from the printing presses, processing it, and saving the results back to the main database. The pressmen were happy for the reduced workload. The managers were happy for the reduced workload. The sales staff were happy for the process run and colour accuracy statistics they could review. All it took was a different set of eyes, being able to step back from trying to force a preconceived notion onto a problem, and recognizing that sometimes it's best to not be too attached to past efforts.
While I don't have a second set of eyes to help with this current project, I can certainly step back and recognize when time is being used in a manner that is ultimately suboptimal. It's time to drop some code and approach the problem from a different angle.
This was back in the day before web applications were a thing. The project was being written in C# with Visual Studio 2005, which had just come out. The target PCs were all 500MHz Celerons with 256MB of RAM, so resources needed to be considered. This was usually enough for most business software, but manager-mandated bloat can do some pretty awful things to code.