Something to deal with correlated failures?

Bugabee
1

This is a half-formed thought, so this is less an explicit feature request and more of a general feeling that there is a missing feature in this pace.

I find failure on my goals ends up being correlated, because failure to make enough progress on them tends to have a common cause - often lack of physical or mental energy to do things.

For example, I have a lot of exercise goals that are somewhat predicated on going to the gym. I can make variable amounts of progress on them once I’m at the gym, but if something is stopping me going to the gym as often as I otherwise would, or meaning I don’t have enough energy while I’m there, they will all tend to become red all at once.

Which means that even though the pledge on each of them individually is quite small (they’re all either $5 or $10), the total amount is relatively large, and the amount of stress caused by them is disproportionately large.

What this means in practice is that I am disproportionately unwilling to let these goals derail compared to how much I’d actually like to be willing to let them derail. For example today I’m probably going to end up emailing support and saying “halp!” because I really don’t feel able to make progress on them today, but it’s a boundary case where I feel like I could probably make progress if it were just one or two of them.

One way of looking at this is that by increasingly using beeminder for fine grained quantified self stuff on my exercise tracking, I’ve made my life worse because of the commitment contracts aspect.

I was originally thinking that what I wanted was some sort of daily total pledge cap, but actually that’s not really what I want either. Perhaps what I want is some sort of derail cap instead - so if I make progress on N of the goals, the others remain red and don’t acquire any safety buffer but also don’t derail. So I still have to “pay back” the progress I didn’t make today, but I am not penalised for not having dealt with so many things.

I don’t know if that’s a good idea, and I’m open to more or less any other approach for dealing with this, but I’d quite like there to be something. This is probably the most stressful part of using beeminder for me, and I’d quite like it to become less stressful.

4 Likes
2

As a stopgap measure, one suggestion is to stagger correlated goals’ deadlines. Forex, if you have 5 exercise goals that should each be done twice a week, set them up so they have different initial safety buffers: the first two goals will derail in 3 days, the next two in 5 days, and the final one in 7 days.

In practice, this is a highly flawed strategy: if you ever derail on one of them, its schedule will be pushed out two days, making it align with other goals. It would take perfect commitment or frequent – and artificial – tweaking to keep the goals in their relative derail alignments. (It also does nothing to help @drmaciver with his current, goals-already-exist, situation; he’s already in the artificial-tweaking phase of this suggestion.)

Regarding an actual solution to the issue: if/when Beeminder gets some kind of goal grouping, possibly one feature of that could be “mutual repulsion.” My (thinking-out-loud) idea is something like this:

– you create a goal group called (say) Exercise. Then you create a goal in this group – say Pushups – that repeats 2 times a week, with a safety buffer of 3 days.
– you create a second goal in the Exercise group: say Running. When you select its frequency and initial safety buffer, Beeminder checks what you’ve already got planned and says, “You already have 1 goal in this group with similar parameters. Would you like to choose a different frequency or initial buffer to keep them from always coming due on the same day?”
– as you add more goals to the Exercise group, Beeminder attempts to spread them out across the week in a similar fashion. (Once you have a few goals in there, Beeminder should probably suggest the two or three best options to you, rather than making you figure them out.)

Some notes:

– Beeminder would use the actual current data at the time you create the new goal. So if you’ve derailed on any of your existing goals or changed their frequency or put them on pause or whatever, Beeminder will look at when they are actually, currently going to come due and optimize the new goal’s settings for the current state at its time of creation.
– This does nothing to prevent goals glomming together once real life happens and you derail or go on vacay or whatever.
– This will probably break and/or be exceedingly difficult for goals that aren’t simple do-more x-times-a-week goals.

So there’d need to be a second part to this, where Beeminder automatically adjusts other goals’ current buffer to optimally distribute them whenever the group’s state changes. Forex, if you derail on your Pushups goal, it might now come due on the same day as your Running goal. So when your derail on Pushups becomes a fact, Beeminder would automatically change Running's safety buffer so the two goals don’t coincide.

The rule could be that Beeminder always shortens the safety buffer, never lengthens it, in keeping with the BM philosophy. That means the new distribution won’t always be optimal, but will be as close as BM can get by adjusting other goals’ buffers to be shorter-or-same.

The calculation effort might well get out of hand pretty quickly as the number of goals in a group grows (I’ll leave the math as an exercise for someone who’s currently more math-motivated than I). Two corollaries:

– goal grouping might need an upper limit: no more than X goals can be grouped.
– goals might need to be restricted to membership in a single group. [0]

I’m sure this is fraught with problems, but it’s a start on an idea for a solution.

[0] This is essentially [1] the first corollary, said another way. It’s just easier for users to use and for Beeminder to implement than saying “a goal can only be a member of multiple groups when the total number of goals in those groups is less than or equal to X,” and it eliminates the need to do a lot of fancy checking when a user adds a new goal to a group or an existing goal to an additional group.

[1] Essentially, but not exactly, because the extra fancy checking means more computation, so the X for the multiple-membership scenario would probably be less than the X for the single-membership scenario. Or, actually, probably not, because the fancy checking would be O(n) whereas the optimization would be O(n!). [2]

[2] Probably not O(n!). I just pulled that out of a hat. I still haven’t done the math. My point is just that the optimization effort will grow far faster than the fancy checking effort, making the fancy checking effort essentially negligible pretty fast.

3 Likes
3

I also tend to find that even without derailing it requires a fair amount of self-discipline - it’s always tempting to do just enough to make a goal not derail, or at best to push it out 2-3 days into the future. Actually convincing myself I need to maintain that staggered buffer is hard.

I like the grouping idea in principle, although it feels like it might be hard to reason about as a user. Maybe that’s not a problem though.

2 Likes
4

I’ve got one small set of two staggered goals, and it’s not perfect.

My approach was to set the slope to 1 per day, and using the autoratchet to enforce actual frequency. When I’m paying attention properly, these goals alternate eep days.

When they get out of sync, I need to do enough to get them back in rhythm, which is more than just today’s minimum, but less than a normal full doing.

5

I have this problem too. There are a couple of approaches I’d like to try:

  1. Only allow one goal within a group to have a nonzero pledge at a time. This requires you not use no mercy and stay on the ball about lowering the pledges when you derail. It’s slightly easier if you have Beemium and can have the pledge cap set to $0 on all of them except the one whose turn it is to be nonzero. (Beemium also lets you jump pledge levels, if $5 total isn’t enough. Or you could allow more than one but fewer than all of the pledges to be nonzero.). I also still find derailing on a $0 pledge stressful, so it isn’t a total fix.

  2. Make all goals within a group have a flat road and $0 pledge. Create a metagoal with a real road and a nonzero pledge. Basically requires some automated way of copying datapoints (with unit translation, if needed) to the metagoal to not be too much of a pain to bother.

What neither of these can handle is a general “get out of jail free card” that lets you, if you have a large enough amount of progress on some goals, eep along without doing other goals (but not indefinitely, just once in a while). I can’t think of any way to do that without fake data (or changing your goal definition to be so unintuitive that some of the data will feel fake) or asking support all the time.

2 Likes