I realize the simple reason is that auto-ratcheting advances your road to the left, thereby moving the weekend breaks. (Does this also happen for manually-added breaks?)
But why couldn’t the road be moved up instead of to the left? If this currently affects user-scheduled breaks as well as automatic weekend breaks, would this ever be what the user wanted? When I schedule breaks, it’s because I want a break between those specific dates, and even if I retro-ratchet I really don’t want that to change.
Yes. Retroratcheting (manual or automatic) does not respect breaks (manual or automatic).
I’m only speculating here, but my guess is that it is these features don’t work correctly together because they are each implemented in the easiest way possible, when considering each in isolation.
Beeminder has no persistent record of a “break”. There is only the road shape data, which is a list of tuples (called “bricks” sometimes). When you use the Take a Break UI, a brick gets inserted into the road. But there’s no metadata recording the fact that this brick corresponds to a break.
When you want to retroratchet, sliding the road to the left usually requires editing fewer bricks than sliding the road up. Although now that I think about it, I’m not sure I actually fully understand the behavior myself. I had typed out an example for you but it was invalid because I was assuming that when presented with a non-monotonic road, the behavior is to set you to the first occurrence of a safety buffer of the requested size. i.e. in this horrible drawing which red circle do you end up sitting at when you retroratchet to 0?
Anyway, I think for normal looking roads you always have to edit fewer bricks to shift left instead of up.
I realize in hindsight that maybe this post isn’t very useful. But I’ve never heard any argument articulated in favor of retroratchet’s current behavior so my assumption is that it is something to do with keeping the code simple.
And for the record I do find it very disappointing that these two premium features, both very desirable and potentially capable of selling me on a premium plan, are completely broken when used together.
Is it too naive to assume that recording breaks as breaks and reapplying them if applicable (e. g.: when start date is now or in the future) after ratcheting would solve the problem?
Intuitively that seems reasonable to me, but I personally find it pretty challenging to reason about these types of things in detail. Beeminder supports a large number of different types of goals (whittle down, weight loss, do less, etc.) and they’re all implemented via very general settings. Aka you have to face the wrath of this table (from Beeminder API Reference):
and convince yourself that your proposal works for every possible combination of these settings.
To be clear, I have no evidence that you’re wrong. I’m just intimidated by attempting to prove you’re right.
Beeminder is supposed to be a tool that helps you accomplish your goals. You’re supposed to be able to say “I created a goal, and now I know that either 1) I’ll do the goal or 2) I’ll get stung”. Your suggestion makes it possible for neither to happen. The hypothetical extreme version of this is that Beeminder never helps you do anything and is completely useless. Sure, not getting charged money makes it “fair”, but the Internet is full of useless things I don’t pay for.
You might say it’s not that likely that a goal would repeatedly fall into the problem of derailing on the weekend, or that it’s “close enough”, but Beeminder is always talking about bright lines being critically important. They taught me that philosophy, and I subscribed to it, but now they have to live up to it. If Beeminder can’t actually give me a guarantee re: 1) or 2) above, then I can’t use it effectively.
It’s icing on the outrage cake that these are premium features. Putting buggy stuff behind a paywall is not a great recipe for success IMHO.
It could also be that there is some technical debt involved behind the scenes which makes those two features too hard to reconcile in a timely fashion, at the moment. Beeminder has a lot of moving parts and only a small team of devs, afaic. And since I assume that not a lot of people have 16$/Month to spare (not to get into a pricing discussion here…) working on refactoring so that relatively few users would benefit is not economically smart, sadly. This paragraph of course makes two assumptions: 1) the problem is technical debt; 2) only few users would benefit from a refactoring effort
@drtall I’m sympathetic to your frustrations, because I have felt the same in this case and that there are still no thought-out tagging and filter features, no snoozing, etc. But I’m also not sure how to demand this thing in a way that actually makes a difference, which is why I kinda think that from a “political” standpoint @zedmango’s suggestion might be not that bad (I understand your gripes with it). If we just say “it sucks” the equation doesn’t change for beeminder if it’s a worthwhile refactoring project, or not.
What do you mean by “technical debt”? That expression does not make sense in English to the best of my knowledge (though I may be unaware of something!)
I don’t understand this. Let me explain what I’m thinking:
If you check the “weekends off” box you are changing your commitment so that you are now no longer obligated to do the activity on the weekends. As I understand it this is implemented by making your rate zero for those days. So if the goal would derail on a weekend your obligation moves to the next weekday.
What I’m envisioning is that you put it in the fine print that you are no longer obligated on the weekends. This is the exact same change in the goal you have from checking the box. And if your goal derails, you’d email support and say “not legit” and they would manually change your road to make it exactly the same as if you didn’t derail, so your obligation would move to the next weekday.
In other words, the effect on both the goal commitment and the outcome is exactly the same as if you checked the box. It’s just implemented manually instead of automatically. So I don’t understand why you say that having it done manually means it’s possible to neither 1) do the goal or 2) get stung, when it’s the exact same outcome as if the break were inserted automatically. When they manually change your road when you call “not legit” to a weekend derailment, they can put it so that it’s how it should be.
I don’t think this is what I’m saying but I appreciate your feedback. Let me try to explain a little more what I’m thinking and you can tell me whether I’m off base?
I think that the context of this particular feature is important. The weekends off feature went live June 5 2016 and it has been premium only since inception. I think it’s fair to say that 2016 is in the “modern era” of Beeminder and so I don’t really consider it to be “legit” technical debt if they cut corners with the implementation of it.
Contrast this with, say, issues related to the lanes concept and how the road dial doesn’t control the critical edge of the goal. These go back to the dawn era of Beeminder and they were actually a genius innovation in the realm of weight loss tracking which is how the whole thing got started. It turns out they’ve come to regret some of those choices, but it got them where they are today. This feels a lot more like legit/classic technical debt to me.
Point being I don’t think I’m here on the forums complaining about things in the latter category. Let me know if I’m wrong! Of course I wish these things would get fixed or improved, but I don’t think we have a right to be indignant about it. But when new premium features launch, I think we should have high standards. Does this seem more reasonable?
Ah, I think I misunderstood your original suggestion. Specifically, I wasn’t envisioning support editing the road. I was just envisioning them reversing the charge. Thanks for clarifying!
I wonder if they will actually do this for somebody long term? i.e. if you put something into your fine print that requires Beeminder support to take action how long will they honor that?
I’m not sure I understand. Regardless of what’s in your fine print, if you derail they email you to check if the derailment was legit and fix your road if it wasn’t.
And I think you aren’t either! I also think that being indignant shouldn’t be the goal and I furthermore agree with having high standards.
But: The simplistic implementation of breaks/ratcheting (which is the linchpin here) makes it impossible to use ratcheting and breaks at the same time (or their automatic versions). And that’s a technical debt here, I think. (I don’t know this though, which is why I try to be careful when saying it…) Also note, that a quick and dirty implementation (“cutting corners”) is a prime example of technical debt.
I couldn’t point to a time when the break/ratchet feature has been introduced (granted, I have also not looked it up…), but in any case imho it’s more important to ask if something is hard to improve because of the implementation or a missing software architectural basis (etc.) as opposed to if this is an old debt or a middle-aged debt. It’s true though, that older debts tend to make improvements harder than younger debts, but this is not necessarily so.
So what I’m saying is threefold: On the one hand I try to describe a plausible technical reason for the incompatibility and on the other I try to say that it might be hard to overcome this specific technical reason. Finally I try to think about what would be a way to solve the problem - maybe a rise in support volume communicates clearer the need for an improvement?
I’m just wondering what would happen if lots of people had lots of goals that have non-legit derails every Saturday and Sunday. I’m guessing they wouldn’t be thrilled about it.
Maybe another way of saying what I’m feeling is: “I think that new premium features should be launched with a minimum of technical debt. Even if they take longer to develop, poor user experience is particularly damaging for premium features. So if they can’t be done robustly then let’s just not do them.”
I think there’s just a little bit of burden reversal going on here. The burden should be on Beeminder to explain why it was okay to launch a new premium feature that is grossly broken in conjunction with an existing premium feature. It can’t be the case that them launching it and calling it “technical debt” thereafter makes it a community puzzle to figure out how to make the feature work.
This is a little tricky. On the one hand, a lack of complaints about this broken interaction might indicate that nobody cares to use the features together and so it was wise of Beeminder to launch weekends off as-is because the extra work spent on making it compatible would be wasted. But on the other hand, users like me who understand the situation aren’t using the features and aren’t writing in to support.
I don’t see why. Beeminder is explicitly designed so that derails get checked manually and roads get edited appropriately if necessary. That’s part of the functionality of the service. Users are supposed to use Beeminder in a way that’s customized to their needs and that involves using fine print and support when necessary.
@drtall I agree that new features shouldn’t already start out with technical debts, so I share your sentiment. But the two features in question are already out there, so in my mind these can’t be seen as new anymore, but rather as to be improved features. And it’s also true that the burden is on beeminder to change this and figure out what actually is the reason. We do have some agency over them however in that we are customers that beeminder wants to have. So how could this agency be used? Answers to that question, in my mind, are the only way to facilitate change as a customer. It’s true, that we shouldn’t need to do anything, but it’s also true that the problem is here. So we either can do nothing and hope or we could think about what we can do, realistically, to change it. Not because we should need to, but because we want to. And I, for one, would love to use both features!
Which is why I tried to say that if, hypothetically, all of us would let all our goals derail on the weekends and let support make adjustments as needed might do the trick.
