Keeping a project alive

Every year I tend to start a few hobby project(s) - I'm not sure exactly why, but I always find a reason to build stuff. In the past few years I've built a few things:

• Ghosty (Private - Automation for publishing this Nurui theme)
• HaloDepot (Halo .map modding depot)
• Biney (Private - PHP Binary Reader/Writer)
• PikminTeardowns (Private - Repo for diffing binary Pikmin apps)
• PiStats (Private - Exports Pihole stats for long term storage)
• Leaf (Halo Infinite Stat Site)

This doesn't even count all the projects that I continue to maintain each year, but I want to talk through some difficulties I encounter and methods I found to prevent project burnout.

Lets start with HaloDepot with some examples. The idea was to build a site that I could just upload a modded patch file and it would automatically extract all the metadata. Like most projects - I spent the initial project work on:

• Repo organization
• Linting / Testing - CI
• Domain
• Automated Deployments - CD

This gets easier and easier since I've done it almost 50 times now, but lets take an example for an individual new to the scene. If you spend the entire time on your project just attempting to get it automatically deploying you may run into some time constraints and burn out.

For me, deploying a variety of PHP applications to a shared cPanel server with different PHP versions kept introducing new issues. Though, even if you are struggling or making slow progress - you are learning something. If your goal is to not learn CI/CD however, then working on the reason you started a project might be a better worth of time. I believe once a project starts to take shape, then the drive and process to do automation becomes easier.

Thankfully, now in 2022 this CI/CD automation with GitHub Actions has become pretty easy. You can see in my 77 line build file I have CI/CD and plenty of features for HaloDepot with little effort.

What ended up killing HaloDepot though? Lets talk about what happens when you bite off too much to chew. If you work in an agile sense you probably remember to take vertical slices of improvement in tiny chunks. This is unlike the waterfall style of things that intend to work on the feature/project as a whole for a long time to perfect and then finally release.

So lets go back to HaloDepot - I decide to support a new patch format that supports 5 different Halo games. I spend time to add filtering & sorting interfaces for tons of new Halo games. I started collecting patches to be ready to seed the completed product.

When I finally started development on the new patch type, I was wiring it up and kept running into issues. This patch format had many different versions so I kept having to perfect my parser to not crash. This would seem like an easy enough task to accomplish, but I could not figure out why my 32bit signed reads were coming up incorrect.

Turns out I found someone else with the same issue. I wanted to fix this package, so I ended up forking it - but it was untouched since 2017 and this was 2020. The CI process was broken and it did not support PHP8 so I became addicted to bringing that project to the future. It was pretty fun to keep a project at 100% code coverage and bring it to the present time with the latest and greatest language features.

Though, I realized after doing all of that - I never fixed the bug which was the entire reason I forked the project. I suffered trying to fix that because my knowledge of pack/unpack and low level bit shifting was rusty. So I tossed that project and built Biney to learn more about this process.

So now I was working on a new package to parse binary files in PHP for HaloDepot while redoing the API from my previously used package. I never completed this and HaloDepot never supported more than 1 patch type. This is because the large task kept ballooning and thus led to a lack of drive to complete it.

The proper alternative to this would have been to launch the patch in a partially supported mode only supporting a few versions and then iterate on each release.

If we pivot again to a recent project Leaf - I had a vision to add an entire new service to do a complex set of actions.

• API against a Tournament Provider (FaceIt)
• Pull brackets and players/teams (FaceIt)
• Automatically match players to Xbox Live accounts (Autocode)
• Pull the game history from those Xbox Live accounts (343)
• Find the online match between Team A and Team B (Logic)
• Include those stats from the automatic games. (Logic)

So like any new thing I was excited and worked on pretty heavily for a few weeks. I found my drive shrinking to work on it since the pull request was ~60 commits, 50 files changed and ~2,000 lines changed without even being complete.

Things I expected to take zero time took too much time and I decided to release it early. I added some under construction messages, hide some features that were busted and released it.

Within the next few days I had a bunch more releases out to fix issues discovered on the live site. I believe its easier to work on a project when you release early and iterate with feedback. Otherwise it falls victim to burnout from spending forever on a feature that will never see the light.