Why does retroratcheting change scheduled breaks?

I basically want to reset any buffers to zero every day to make sure I work on my goal every (week)day and just because I worked better today should not mean I get tomorrow off.

From the information I gathered, this could be achieved by retroratcheting. But this seems have also changed my scheduled break which now no longer fall on weekends. Can anyone explain why this should be and how to fix it?



Sorry about the confusion and frustration here! Part of the answer is that ratcheting a yellow brick road is inherently confusing. To get rid of safety buffer on a do-more goal when you’re above the road there are multiple things we could do:

  1. what we now do, shift the whole road to the left
  2. shift the whole road up
  3. change just the current segment of the road

Well, (1) has the problem you encountered, of changing the dates of the scheduled breaks. And (2) changes the eventual target value, sometimes making the goal impossible to achieve (like reading more pages of a book than exist, for example). Best of both worlds could be (3) but that can also be confusing by making the upcoming road shallower than you wanted, or if you have enough safety buffer to carry you past your next break then it’s especially confusing how to make the new road nonconfusing.

It’s probably common for (2) to be just fine, like for open-ended goals. But (1) turned out to have the cleanest implementation. Sort of.

I think the right answer is to improve the road editor interface and let that be the only way to ratchet and schedule breaks and everything else. Then the user always has full control and sees the repercussions of all their changes, with everything easily undoable, etc.

We shall get there! In the meantime, when your road gets messed up, holler at us at support@beeminder.com and we’ll fix it.

Thanks so much for reporting this buggishness! Hugely helpful to us!


I think retroratchet is really useful. It could be implemented as assisted editing for the road editor, but I wouldn’t want it to go away.

Can I suggest making use of the information the user has already provided? Specifically, if they haven’t entered a goal total, you should shift the road up. If they have entered a goal total, you shouldn’t touch the total (see New UI date/total/rate pain point). In this case, if they’ve also entered a goal date, you should change the current segment (this is a hard deadline). If not (they’re using total and rate), shift the goal left.

EDIT: I’d advise adding some explanatory text to the advanced “Commit To” settings as well, saying that whichever fields you’ve set explicitly here, Beeminder will try to preserve them as much as makes sense across ratchets, derails, and other things that change your road.


Agreed about keeping the notion of ratcheting – a simple way to shed excess safety buffer – regardless.

And @kenoubi’s proposal sounds right – shifting the road up or left (or the equivalent for do-less) depending on what subset of {goaldate, goalval, rate} the user cares about. But the amount of magic entailed should be setting off lots of alarm bells. My hunch is that the UI should only be so presumptuous – guessing the right way to adjust the road to achieve the ratcheting – if it’s also very transparent and undoable. So having this be part of the general road editor.

1 Like

I think this is just a symptom of the more fundamental problem that the YBR doesn’t have any notion of why each brick was created. This is why retroratchet, take a break, weekends off, derailing, etc. often interact with each other poorly.

IMHO manipulating the road would be a lot easier if it were build in layers like a Photoshop image. The road dial and retroratchet work on the same terms and you can shift that layer up or left easily. But take a break and weekends off are fundamentally not the same and ought to be layered on top.


I’ll keep repeating this until it sinks in: Every action that decreases your safety buffer* should prompt you, asking whether you understand what’s going to happen, and give you a way to back out of it.

If just that one thing were true, the “magic” here would no longer be scary.

* EDIT: with the possible sole exception of “bad” data points (e.g. negative data points on a do more road). Though it still should not be possible to instaderail yourself this way.


Reasonable! But the fully general case of asking if you understand amounts to

your yellow brick road used to have you getting to this value by this date at this rate and then to that value by that date by that rate, etc etc … and now it’s going to change to blah blah blah blah blah…

Or a more generic version would amount to

WARNING: this changes things about your road you might not want changed; are you sure?

But just having an undo button would help a ton.

1 Like

On the one hand, it’d be awesome to be able to more easily edit the road.

On the other hand, this also sounds like pushing the burden of complexity onto users.

On the gripping hand… [rant] let me just hijack this thread for a bit, soz in advance.

Some of the magic that @dreev perceives might drop away if we knew explicitly whether the goal parameters were somehow ‘real’ and related to the outside world, or if it’s part of endlessly striving to do/be better. (Some endless striving goals are just being tried on for size, like a 30 day challenge, which it’d also be great to support for real.)

I don’t read this thread as being about the road segments, but about the symptoms that result from us hacking ‘breaks’ in over top of the data structure that we had. (Not dissing the implementation, I’m much happier to have it than not!)

We’ve got a growing list of things that should be proper entities in their own right, rather than being disguised as ordinary entries in the road matrix or the datapoints. Breaks are one, ratchets are another, derailments too.

At some point we’ll sit down and revamp the entity model, and that’ll also give us somewhere to hang milestone markers and other features that occasionally come up in discussion.

Also: undo++



Indeed, I think this is why I ended up finding the road editor trial less useful than I expected I would. (Well, that and lacking control over the critical edge.).


Can I suggest the middle ground of “this will decrease your safety buffer to N days” (or “this will immediately derail you”)?

The other replies here are true, but they amount to creating a big new project. I really think just doing this one fairly simple thing would make Beeminder significantly better (and reduce the amount of work I personally create for support, and I imagine other power users as well).

1 Like

Ooh you said milestone markers! So glad this is indeed in the works.

1 Like

I’m liking a lot of what @philip has said here. In my experience,

is pretty much the opposite of the general road editor. I really appreciate being able to give it a try, when I want to get fiddly with a road, but I think more than half of my attempts end in emailing support to ask them to fix my terrible mistakes.

Between “retroratchet magic” and “a perfect road editor,” I think I’d experience the benefit of retroratchet magic more often – I’d love to use the road editor to set of a road with a basically-exponential curve toward a deadline, with breaks/resets at key points, in accordance with my work patterns (which I am sure I could technically do now, but haven’t taken the hour+ to figure out how), but I would get 80% of that benefit by being able to more reliably control the road via a real-life target and deadline. (My current annoyance is that breaks seem to steepen the road only after the break, when really I’d like to steepen it beforehand also, and retroratchet+fixing the deadline gives me flat spots at the end.)