💾 Archived View for ainent.xyz › gemlog › 2023-04-20-project-scopes.gmi captured on 2023-04-26 at 12:51:21. Gemini links have been rewritten to link to archived content
-=-=-=-=-=-=-
Some time ago I got tired of my seemingly never-ending todo list, full of technical project ideas (not necessarily software development), personal tasks, etc., and decided to strip it down to the bare minimum. To stay on the list, it had to meet a few basic requirements:
I'm probably missing something but this covers the basic ideas. This cut my todo list down to almost half its size, when including recurring and non-recurring items. Half! Not only did this remove a huge (self-imposed) burden from my mind, it also motivated me to actually work on more of the remaining things. A long list of stuff that part of you knows will likely never even be started is quite the demotivator, especially for someone who is motivated by quantifiable progress metrics.
In my years of hobby software development, I have lost count of the number of projects I've started then abandoned. I tend to lose interest, then never return. All or most of those projects, while serving specific purposes, had enormous scope potential; let's face it: for part time projects, they might as well have been infinitely scoped because, in hindsight, my vision for them was just too broad to have any hope of completing them with part time effort.
`smolver`, on the other hand, is necessarily finitely scoped due to the immutable nature of the Gemini protocol spec. Granted, yes, the project's scope has grown since my initial vision for it, but once it hits full feature parity with the spec, that leaves just: bugfixes, refactors, dependency and Swift language upgrades, and administrative (as opposed to end-user- or client-facing) features. The latter should take up the bulk of the time, but even then, there are only so many admin features to implement for a static protocol. It is my first finitely scoped project and it is unbelievably refreshing. This finite scope is a motivator, exciting me for other small project ideas, and causing me not to abandon the project.
Ironically, unit tests are expanding the amount of work, but that is just the nature of unit testing and test-driven development (TDD). Ultimately, though, that is a good thing because it'll prevent regressions when refactoring... not to mention the nightmare that manually testing all the client certificate and CGI scenarios would be. That said, I do have a bit of a love/hate relationship with unit tests. The reasons for that could be in their own separate post, though.