Stop Rewriting and Start Fixing

Once, I inherited an application so offensive, it felt like a personal insult. It wasn’t just bad code, it was a decade of bad decisions stacked like a Jenga tower. My task was to address a complaint by the internal users on a report that was generated.

I looked in the company's git repository for the tool, but it was nowhere to be found. Only after digging through the server it ran on, I found that it was using Concurrent Versioning System or CSV, a version control system older than some interns.

At the root level, there was a file index.php. There was also a file called run.pl. As I dug deeper, I found .sh files. And some .js. In fact, all of an Angular project structure was in it. But click on the /bin folder, and there were a couple .exe files. And a .COM of course. For every layer I peeled, another programming language popped its head like a Jack in the box. These were not remnant files that a developer forgot to delete. These were all actively in use to run a single application.

I had to run an investigation. I traveled several floors and interviewed people to understand how parts of the application worked. I tracked down the original intern, now a big shot with her own office. She sipped her latte, leaned back in her chair, and spun a 10-year yarn about grep commands and Perl scripts. I left with a history lesson but no answers.

I clenched my jaw when I found a Window XP machine sitting in the server room. It ran a small but important part of the application. I threw my hands in the air. "That's it! I'm rewriting it."

This wasn't my first time attempting to rewrite an entire application because I thought it sucked. However, I had not learned my lesson enough to understand how monumental the task was.

At the time, this application was already 10 years old. It was started by the intern who wrote a single grep command that would look through a bunch of logs to identify known errors in a set-top box. The command turned into several commands to parse multiple errors. Then the commands turned into a bash script. Then Perl was added to connect to MySQL and save the entries. Then PHP was added to view those entries via the web. Somehow .COM was added to run on a remotely connected Windows XP machine sitting in the server room. But then Angular, because you can't have a project without Angular.

My theory was each of the interns that worked on this tool over the years brought in their own experience, programming in the language they were familiar with. This tool had become an important company asset and they couldn't afford it to break down. So they brought me in to maintain it.

I was young and excited, so I started rewriting the entire thing in a nice well structured Symfony project. I spent a week reading code, and converting it to PHP. I made the website responsive, and gave it a nice design. I properly displayed the data on the page with correct HTML. I removed the hard coded username and password in the cookies and stored a session token in Redis. I was the hero replacing this Frankenstein code with pristine Symfony masterpiece.

But then, when I ran the command to parse the logs, it failed. I tweaked the regex and ran it over and over to no avail. I even copied the grep command from the bash files to PHP and for some reason it didn't work.

"When’s the fix coming?" The team started pestering me about the bug they wanted fixed. I did not want to fix it. I did not want to sully my fingers with their dirty code. I wanted to offer them something better, something written properly. The regex failed. I tweaked it. Failed again. I copied the original grep command, still nothing. My pristine Symfony masterpiece was a house of cards. The old code was ugly, but it worked. My ‘perfect’ rewrite didn’t even run.

I was stuck. I gave in. I fixed their stupid bug and let them know.

I kept working on this project for my own sanity. I couldn't just leave it be. But the more I dug into the code, the more I discovered. Unknown unknowns lurking in every script. Over the course of a month, my shiny rewrite covered less than 5% of the app’s functionality. I gave up. But in giving up, I found a new role: not the hero who fixed everything, but the guide who understood the chaos. I became the keeper of the mess.

I've made several improvements to the tool. Instead of using a flashy new framework, I documented how to run the application in its current state. I've consolidated parts of the application that dramatically improved performance. Perfection wasn’t the goal. Progress was.

I stopped fighting the chaos. Instead of Symfony, I wrote a README. Instead of rewriting, I documented. I traced each COM file, each Perl script, and mapped the madness like an archaeologist. The team didn’t need a hero. They needed a guide.

The parser used to take close to 8 hours to run. MySQL was groaning under amateur code, all because of the poorly managed connections. I've restructured it to write to disk and then bulk import the results to the database once the parsing was completed. The runtime went from 8 hours to 17 minutes. This meant we could now use the web interface during business hours.

This wasn’t about code. It was about understanding chaos instead of fearing it.

I once read a comment on the internet about why developers hate PHP, yet PHP was still the main programming language powering the web. I'll paraphrase it:

We know that PHP is broken, but we also know how it is broken.

Like PHP, this app was a mess. But now I knew its cracks. For the most part, I kept all the funny little languages as they were. I understood that you can’t fix 10 years of chaos in a week, but you can make it manageable. I added documentation for future developers. It was still a mess, but now it was my mess. And that made all the difference.

---