The Great Refactoring

I am not a software developer. My education was in mechanical engineering, and the totality of my software training was a couple of first-year university courses learning the basics of C++ and JavaScript. And so it was, as I embarked upon this protracted entrepreneurial journey, that I pieced together whatever code was needed to make the PhyzBatch-9000’s software functional. The result? I built a working system, but if a seasoned developer were to peek behind the curtains, they would likely hemorrhage through their eyes until they died, screaming all the while.

Moving forward in time, I found myself in the most fortunate position of having a successful commercial product. That success allowed me to grow this company (such that the “I” became “we”) and for us to hire proper, formally trained developers onto our team – people far more talented at coding than I will ever be. While this was all well and good, these new developers were placed in the rather awkward position of having to maintain, support, debug, and build upon my terrible codebase to keep things running. With each new feature request, the Dev Team’s collective sense of anxiety grew, as they were effectively being asked to build a skyscraper on top of a rickety foundation constructed by someone who had no advanced knowledge of modern building techniques.

WELL NO LONGER! At some point, you need to say, “Enough is enough!” and proceed with the laborious – but ultimately necessary – action of doing things properly. In software development, this maneuver is known as “refactoring”, which essentially means that we are restructuring our existing code so that it no longer looks as if it was written by an attention deficit orangutan. Refactoring is no one’s idea of a good time. It is not exciting. It is not sexy. It is a slog. But, once complete, our refactored code will open the door for us to roll out new software features much more quickly and with greater stability.

For those of you who have been wondering, “Where the heck is support for Yu-Gi-Oh! or Flesh and Blood?”, this is your answer. While we could have rolled out support for additional card games earlier, we would have been continuing to build upon the already precarious and unstable foundation, knowing full-well we would have to tear it all down and build it again properly in the future. Well, the future is now! In fact, our team initiated the refactoring process a couple of months ago, so we are already a decent way down the road. With progress continuing at its current pace, we are targeting a migration to the new code base in January 2024.

Testing with the refactored codebase is already looking fantastic. Aside from the code being more modular (making it easier for us to add new types of cards), there’s also a considerable increase to card recognition accuracy, and even a speed increase to boot! So, while the refactoring process itself may be tedious, ponderous, and just a real big pain in the ass, the results will at least be worthwhile.