Software Launch: Adapt and integrate FTW Part 0

This the beginning of a series of blog posts designed to discuss the technical challenges, mishaps, triumphs, trials, and tribulations encountered whilst marching towards the initial launch of our Screenwriting software platform, sagittly.com. Somewhere along the way, there may even be some anecdotes about success! But really, this is about the struggle. Beginning the Journey

Sometime during the pandemic, I was approached by my best friend (who also happens to have been the Best Man at my wedding) about a possible project. Now, I wasn't too keen at first, with taking on a new time commitment - what with my family, full-time job, etc... But I heard him out and really liked what they were trying to do; plus, it would provide me some technical challenges that I wouldn't otherwise encounter during the course of my regular day job. Ah, I should mention, I'm primarily employed currently as a Backend Engineer at a Health InsurTech shop--that means python, Django, etc..--though I've also spent over a decade professionally on the systems/ops side as well. On top of that, I possess some (admittedly dated and enough-to-get-the-job-done) FE skills. So this whole launch should've been fairly straightforward, right?? Absolutely not.

Laying the Groundwork

At the core, our application is very simple: We are 100% hosted on Heroku, use React for the frontend, nodejs for the backend, firebase as the datastore, and a small python web service for some additional processing. But of course, as with most things software, the devil is in the details... For better or worse, I inherited a codebase. To further complicate matters, all the software had been written by a single developer, so you can imagine the shortcuts one might employ were one in that position. And I had never used Heroku, nor did/do I profess to be a proficient node developer by any means. So, this is the situation I found myself in.

How did I proceed? I began the way any self-respecting software engineer would begin: local setup and testing. The local setup was easy enough, though one goal was to use the same IDE for python bits as well as the javascript portions. I use PyCharm professionally and had initially considered that same for this project, but I wasn't necessarily open to charging the license cost to our fledgling business. Enter VSCode: I had _heard_ mixed things about VSCode and know at least one colleague who is a massive supporter. This was the first of many mistakes. Coming from a paid IDE to a free IDE will always be an adjustment, but the switch from PyCharm to VSCode was simply not worth the cost savings in license fees. Not only did it take several hours of research and tinkering to get both a python project (Flask) and a react/node project setup with full debugging capability playing nicely with one another; once this was all set up, the workflow felt... clunky. After dealing with orphaned server processes, misfiring breakpoints, heisenbugs influenced by the in-IDE runtime environment, etc., and a largely unintuitive UI for a week or so, I finally took it back to basics and just setup vim as my main IDE for this project. My honest--if unsolicited--advice is to stick with what you know in terms of IDEs or any other such core tooling; even if this means shelling out for license costs (within reason); the amount of time you will likely justify the cost. Now that my local development environment was established, the next step was to run the software through its paces; i.e., exercise the tests and reproduce any high priority bugs that were already in the backlog (Feature and Bug tracking are for another blog post). Of course, the test coverage was sparse to nonexistent, turning this from an exercise in exploration and discovery to one of hazard avoidance! On the next blog, we'll jump into some technical details and talk about the experience of progressing through a feature backlog, all the whilst attempting to preserve existing functionality in an already-existing deployment of difficult-to-trace, modified versions of related repositories, each containing code with limited test coverage.