Principles for Progress

2025-06-20 (Mod: 2025-06-23)  |   6 minutes

I started this project over a month ago, but then immediately got sucked into the frenzy of getting my web system finished. So now that Project WebSmith is almost complete, I can finally turn my attention back to Plim.

But I need to proceed cautiously.

◇◆◇◆◇◆◇◆◇◆◇◆◇◆◇◆◇◆◇

As I may have mentioned elsewhere, I find meticulous detail work to be tedious, which explains why so many of my projects are currently stalled at the “getting it ready for release” stage. It also means that I don’t have much patience for the entire field of accounting. So for me to be writing a financial app of any kind is slightly insane.

But I’m so frustrated by existing tools in the budgeting space that I’m motivated to wrestle my impatience into a sack and find a way to get this done. To that end, I’ve come up with a few guiding principles I’ll be using for this project. And, to be honest, they should probably apply to my other projects as well.

Principle 1: Publish First

I’ve redesigned my entire workflow to embrace my distractible nature. As a consequence, I’ve had to recognize that many of my projects falter in the gap between “it works” and “it’s ready for release.” But if those stumbles at the finish line become permanent, all that work, all those projects, are wasted, because nobody ever finds out about them.

This new web system, which has me publishing my working notes and progress reports along the way, is a good first step in sharing the ideas, but it doesn’t go far enough. Projects like Plim are useless without their code base, so I need to share that too. That way, even if I get so distracted that the project falls off the table completely, anybody who stumbles across it later could conceivably pick up where I left off.

Consequently, I’m going to push my development code to a public repository immediately, rather than waiting for the fabled “public release” that may never come.

Principle 2: Publish Often

This is an obvious extension of P1, but I’m making it explicit. Having a public repository of my code would be useless if it wasn’t up to date. Historically, my practice has been to maintain a private repo on the file server in my lab and push checkpoints to that. So the easiest way to ensure my public repo is always current would be to eliminate my private repository entirely and use the public one instead. (I’ll still keep a repo on the development machine for incremental steps, but all checkpoints will get pushed directly to the public server.)

Principle 3: Have a Strong Metaphor

Since Plim is in a domain outside my comfort zone, I need to maintain a clear vision of where I’m trying to take it. For me, that means establishing a metaphor I understand more instinctively, and then using that metaphor as my guide.

Fortunately with Plim, I already have the whole concept of shooting holes in wooden buckets. From the outside, that may seem like a quaint marketing gambit, but for me, it’s an indispensable part of the equation. If it’s well enough structured and detailed enough, I can think in terms of the metaphor rather than the less comfortable domain it’s masking.

From time to time, when I’m feeling especial sharp, I’ll still need to double check my metaphor-based decisions against the project domain, but for most days, sailing by map should be good enough.

Principle 4: No Foggy Days

Yesterday, I tried to get some work done on Plim, but I’d been fighting a cold all week and hadn’t been particularly sharp, so, predictably, I spent two hours fumbling with the code and getting nowhere useful.

Today, feeling much more clear-headed, I looked back at those efforts and just had to shake my head. Clearly, there are some projects that I can work on when I’m a bit muddled, but Plim is not one of them.

From now on, I can’t let myself work on this project (or any project that I find “tricky”) when I’m not up to snuff. Or alternately, I have to come up with “fuzziness-friendly” tasks that I can work on if that’s the kind of day it is.

Principle 5: Post the Metaphor

Another thing I noticed yesterday was that, even though I’ve conceived a detailed metaphor, I couldn’t remember where I’d put those notes, so there was no easy way to remind myself of the details. Had a concise summary document existed and been located in a predictable place, I might not have struggled in futility the way I did.

Of course, such a document would also be of enormous value to anyone trying to understand the code, so this is actually a valuable piece of project documentation, and I already have a place for those: on the project landing page, in the Related Documents section.

Learning from that experience, I’ll now have to draft a one-pager that lays out the vision, design philosophy, and next moves. I’m calling it the “Koolaid” file - the quick communion cup of my own cultish vision. On clear days, I’ll use it to regain context and momentum. On foggy days, I’ll follow it blindly - no matter what it tells me to do.

Principle 6: Text Wireframes

Many of my projects (eg FrankenTongues, Vulcan Solitaire, Maranga) employ a design process I think of as iterative bootstrapping. It starts with building a command-line text interface first, which is dead simple and lets me quickly flesh out the basic operations and internal data structures. This sketch then feeds a TUI interface where I can work out some basic screens and layouts, before finally proceeding to the more complex full GUI suitable for general users. But crucially, each of those interfaces remains a functioning and valid way to engage with the tools, and all of them are fully interoperable.

As that workflow demonstrates, I’m already embracing the idea of using simpler systems to sketch out more complex ones, but for some reason, I’ve never taken advantage of the most obvious sketch at the very start: using a text editor to plan the proposed displays for that first terminal interface. If I’d had such sketches to work from yesterday, I might have actually achieved something useful. (See the note about fuzziness-friendly tasks above.)

Additionally, I’m keenly aware that much of this current website is me talking about my projects and their intentions, but in many cases I have nothing to show you yet, to help you see the vision floating in my head. Text screens might not be the kind of whiz-bang collaterals one would use to attract customers, but as a schematic representation of what I’m aiming for, it would be way better than the current nothing-burger I’m offering.

And as a guide for early implementation, they will do yeoman’s work, by not only establishing a target, but since I design them independently of coding, they will also let me focus on what’s most useful to the user, rather than what’s easiest to code.

Plim Next Steps

So in light of these principles, I’ve got my next few steps mapped out for me in Plim:

• Post the details of the bucket metaphor and architecture in a KOOLAID.md that can be used as a recap. (See The Bucket Codex.)

• Decide where I will be publishing my git repos (See Looking For A New Home)

• Publish the Plim repo

• Post a list of command-line operations (See Command Index)

• Post text wireframes of the crucial screens (See Crucial Displays)