Beeminder Forum

Recommits & losing safety buffer: Flat period vs. plummet ("slide down/up")

Thinking out loud here about my own (yet unpublished but to-be-open sourced) beeminder-like tool, but maybe this is of interest to beeminders as well as to me since I believe beeminder is heading in a similar direction re half-plane, and maybe with how losing safety buffer works? Certainly I’d love to hear feedback from people’s experience with beeminder.

This is all about recommits, and also losing safety buffer, which I’ve modelled essentially just as a recommit that goes up instead of down.

How should recommits and losing safety buffer work? At least in my system it seems there are two obvious choices, one of which only became clear to me after using it for a while.

Choice 1: (I believe this is at least similar to what beeminder does currently?), recording a recommit causes the goal line to drop a little bit to the cumulative value of the last datapoint, followed by a flat period where the line stays horizontal. After that it starts going up again at the same rate as before the derail.

After using that for a while, I found two problems with it:

a. I found I was encouraging myself to ignore the goal after a recommit, because “I’m losing nothing”: after all, the horizontal distance from the last datapoint to the goal line stays the same if I do nothing!

b. I was encouraging myself to ignore it ALSO because the drop from where the line would have been without the recommit, to its new value (that of the last cumulative datapoint) was quite small. That felt like I was leaving motivation on the table, because it made the consequence of derailing look less bad than it really was.

So, Choice 2: Recording a recommit causes the right hand side (the future side) of the goal line to “slide down” so today’s value matches the last cumulative data point. Then instead of the flat period, the line just starts increasing again immediately from that much lower value. It slides down just enough so you have 7 days of safety buffer.

I think of choice 2. as “plummet”, because it makes the real effect of a recommit visually very clear.

The situation for losing safety buffer is similar (again, in my system losing safety buffer is basically just a recommit that “slides up” instead of down). I believe beeminder currently “slides left” instead for losing safety buffer, which has different problems (e.g. moving scheduled breaks).

I’ve switched to the “plummet” scheme now both for recommits and losing safety buffer, and it does seem an improvement. Still, maybe there are advantages of the “flat period” scheme that I haven’t noticed?

By the way – I haven’t had any recommits for months, except for one goal where I realised I didn’t really have direct control over the data points, so THANK YOU to @dreev @bee and everybody else at beeminder, and in fact everybody on this forum – I’ve been reading every one of your posts for a long time, so if you ever wonder why you’re posting, all your ideas and experiences are certainly appreciated here :slight_smile:

Time will tell, but at the moment I feel like this is a significant positive change in my life. I feel committed not just to my own prior goals, but to do what I can to help spread the idea.

PS the point at which I broke everything in my codebase is super obvious in the charts: foolishly, I didn’t just install an old copy to use day to day while I reworked everything from my initial hack, so the system stopped working entirely for a while. Looking back, it’s steady upward progress (initial hack), then just a series of constant derails while the system wasn’t working right, then back to constant progress as soon as it started working again. Mind you, you could say with some truth that part of that was just that I was spending a lot of time on developing it rather than doing my other goals!