Project Scopes

General TODOs

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:

Realism! Not some pie-in-the-sky cool project that might be cool to do one day if I had unlimited time. I applied this both to technical and everyday life items.

Not be something so common as to be already ingrained in regular habits/chores

Not be something so fundamental to comfortable life that if it becomes an absolute necessity overnight, there is no way I could forget because it'd be staring me in the face every day

Not be something that, while relatively important, is something that simply can't be forgotten because it is already staring me in the face everyday

Be something fundamental to household maintenance but is needed so infrequently (but also in regular intervals) that I am likely to forget

Must pass a mentally-calculated cost/benefit analysis

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.

Finitely Scoped Software Development

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.