Thoughts on abandoning my side project

 
In 2017, I started gitDash, an application for tracking git branches, their commits, and where they were in your build pipeline. We use a development flow where we have a branch associated with each environment, so it is easy to see what commits are in each environment and whether they have made it to production yet, but it would be nice to have a dashboard for this. We also have specific branches that are used for testing, and it would be nice to have a dashboard to see which of these has not been used recently and is free. These were the two scenarios I was trying to solve with gitDash, but with a slowdown and another solution to the problem, I ended up neglecting and eventually abandoning the project.

A dramatic slowdown

 
The primary reason I failed to finish my 30 days of dev with gitDash was I hit an issue that didn't have a good solution. Mergeability is not accessible through the github API unless you create a pull request, so gitDash had to create a pull request to see if one branch could be merged into another. Creating a pull request could trigger many side effects, and while this is the solution I ended up picking, I wasn't happy with it. Creating the system for opening a PR, checking the mergeability, and closing the PR took a lot of time and ended up killing my motivation to continue the project

The key lesson I learned here was to more concretely define what I was making with my side project and make sure it is all reasonably possible. The assumption that mergeability was accessible via the API was also a huge mistake. The checking of mergeability took almost as long as the rest of the project up to that point. Mergeability was in the original concept, but probably wasn't completely necessary to create a simple MVP dashboard that accomplished my goals, so once I had found that it was not easily accessible via some property in the API, I should have removed it from the scope of the project.

An alternate solution

One of the key problems that the dashboard was supposed to solve was identifying who was using which development environments and what was on them. One of my coworkers made our development environments obsolete by having the ability to create environments on the fly by including something in the commit message. Once there was an alernate solution, half the use case of the dashboard was unnecessary, and the rest of motivation for continuing my project was gone.

Lessons learned

 
The biggest issue with creating gitDash was I wasn't that interested in it. There was a need, but not a big one. The driving motivation of continuing the project was writing about it, so once I hit a few snags, there wasn't much reason to continue. This year I've started a new project, Deimos, and while it is a much larger project, there's no way I'm going to run into the problems I ran into with gitDash.