You are always refactoring.
A “true story” about how Project Managers should get used to refactoring. It will never stop as that is the natural flow of the product’s lifecycle. And team maturity.
A prologue
I was always into photography and passion lasts about a decade now, I had reached a million captured photos 2 years ago, countless selfies, burst shots, and captured moments. Somewhere along the way, I would skip classes in college to attend meetings with my photography mentor Brane, after that, I would become a president and mentor to a group of 50+ enthusiasts in a local photo-club, be a wedding photographer and work in spherical, 360-degrees camera startup.
The seed
I had an idea for a couple of years now. An idea to capture timelapse from my favorite hill. To capture thousands of photos. And then do something with it. That idea sat with me and lurked in the dark. Here the story starts unfolding.
After burnout, and soon after, Corona, grounded me and locked the rest of the World, I picked an old Raspberry Pi that I had for ages and never did anything useful with and, inspired by my recent Sledilnik.org contributions, coded a very simple bash script to randomly showcase over 18000 selected images of my girlfriend and me. Then, I may have or may have not bought a camera module.
version 0
I coded first bash commands, set up a basic timelapse, and was disappointed quickly. It didn’t work as expected, the module itself wasn’t the best and most of all, the files could only be named sequentially (as if image_0, image_1…), not as I expected (hh_mm_ss, hh_mm_ss…).
I quickly realized this will not be enough and searched the interwebs furiously for a solution. I found a Python script that did just what I wanted. Life was good for a day, I couldn’t be more proud of myself.
version 1
Now I had a timelapse that started and finished by the hour and would restart the next day, whoah — tectonic changes. But that wasn’t enough, so I coded an automatic creation of the timelapse movie that combined all captured photos as frames. Now I had movies.
That wasn’t enough either, so I coded in image compression, backup HDD storage, and automatic upload to Youtube. Log “became available” around the same time, as I was tired of debugging it on the fly, and would rather leave the camera to run for an hour before checking on it again. The codebase was around 800 lines.
I showed my progress to the local Python community and boy, were they harsh on my hackish coding. They gave me guidelines on what to do and so I went through the same code again.
version 2
I remember the look on my face when I spoke with my girlfriend that night, how I “worked all day, and as a result, the camera doesn’t do anything new, but the code is cleaner”. I couldn’t even believe myself, how I wasted the whole afternoon so that I could make the code 300 lines lighter, how it might run a tad faster, and that the result was the same as before.
After that, I immediately started another rewrite, where I added web upload and hacked a simple React site to see my progress live. I also put the camera at the best spot to start capturing the view at my parent’s house.
I fixed bugs whenever I visited. I climbed that ladder numerous times. It got normal to me, even obvious. I rewrote the whole codebase twice more without having the camera to test on, as the only model was “in production” 1-hour drive away. At some point, I bought more cameras.
version 3
I stumbled across scenarios I didn’t anticipate. Power loss, full SD cards, full backup storage. I started talking about users, what users want, will want in the future. Without having ANY users. It’s funny now, but I was dead serious. I started planning MVP, and all of a sudden, autonomous flow that was perfectly good enough for me wasn’t nearly as flawless when I imagined that I would have to support this for customers, explain how it works, give warranty for it, etc.
At that point, all camera parameters were still hardcoded. So I created user settings files. I created manuals. Started writing articles on setup. Started experimenting with different products. Learned Django to build a web page, that would enable more tracking. Built that web page. Set milestones. Failed to reach milestones as I was refactoring, and while at it, I added more features such as Sunrise/Sunset recognition based on geolocation, better file-naming, and file-handling, overnight, and by the minute “precise” capture, and so on.
Conclusions about rewriting
The list of features is growing still, the beta-product is almost ready to be publicly unveiled and offered on the market, and most importantly, I learned a valuable lesson. As products evolve and grow its only natural to expect changes in the core, as at some point in time, it’s not suitable for the product and has to be changed.
After a couple of months, my codebase doesn’t even remotely resemble the first version anymore. Because it evolved and I evolved with it. Now I know there is nothing wrong with “ it’s just another rewrite where we will waste time” because I know that more functionality and overall better products will come out at the end of the tunnel. Consider it ground-work for future success.
As the product matured, I rode shotgun and was able to watch the idea unfold and solidify in front of my eyes for the first time. Being in charge of the vision and the development forced me to think differently and to understand the founder and developers I work with more, to look at the problems from a different, previously unseen angles.
To come full circle, the motto Change is the only constant never felt so close. As much as concerns me, rewrites in all shapes and sizes are welcomed now, as they enable us, and our products to grow.
What are your thoughts about change? Do constant rewrites feel more like a burden or a relief?