Using support like @zedmango suggests makes me uncomfortable (they’re such nice people; should we really be bothering them all the time as a backdoor to using a feature that the company as a whole hasn’t seen fit to fix yet?). On the other hand, the fact that it would make it abundantly clear how much benefit this fix would create for their community does make it tempting.
3 Likes
I think seeing it that way is a mistake. Part of the beeminder service is customizing your goals to your personal needs using the fine print; this is just a special case of that. So it’s not a backdoor to anything - it’s part of how the service should work.
2 Likes
I want weekends off for certain goals but I don’t use the feature because I don’t have a premium account[1]. I also want certain weekdays off for other goals but the weekends off feature isn’t configurable or very generalizable.
I wrote Beelint for myself which is fully configurable and also examines your Google Calendar to find incompatible days (Beelint: Another take on weekends-off & vacations).
[1] The #1 thing that would get me to buy premium is autoratchet improvements, namely I want records of when autoratcheting happens and I want IFTTT triggers to fire when autoratcheting happens. I also want autoratchet to work with weekends off. TL;DR if weekends off were free I would use it as-is, but if I had premium I would actually rather use autoratchet since I’m forced to choose between them.
2 Likes
Sorry, by “doing that” I meant “putting it in the fine print.”
It’s kind of odd that the “weekdays off” thing requires a premium but the more general “non-legit derailment if your conditions aren’t met” doesn’t.
1 Like
I’m stuck because I agree with both of you. I am persuaded, rationally, that we should use the service as @zedmango is describing. But the thought of actually doing it makes me uncomfortable.
2 Likes
Why?
Which of the following situations would make you uncomfortable calling non-legit, assuming that the fine print allowed it (setting aside the question of whether or not you’d actually want to put it in the fine print):
- it’s your birthday
- it’s a close friend or family member’s birthday
- a close friend or family member is unexpectedly in town
- a vacation planned ahead of time
- some type of holiday
- you’re sick
- you’re overworked with another job or project
It’s not about the situation’s nature, it’s about whether the situation is low frequency / rate limited or if it is potentially high frequency.
Everything you listed is relatively low frequency compared to 2/7ths of all days.
For example, if the fine print were “Odd numbered days off” then I would be interacting with support a lot.
1 Like
So it’s the amount you might have to interact with support in a worst-case scenario?
What if you were interacting with support just as often but for different goals each time? That is, is it the amount per goal that feels like a problem (“I’ve bugged them enough on this goal”), or the total amount across all your goals?
I think it’s per goal and I think it is also a question of how foreseeable it is. If I say “I’ll contact support whenever I am sick or overworked” this is less foreseeable than “I’ll contact support on odd numbered days”.
To be clear I’m not arguing this is rational. 
1 Like
Because if it were foreseeable - what, you should have written a program to take care of it?
No, not exactly…
Like, on the two extreme ends, I feel like these resemble:
- “Hello, support, I’ve been struck by lightning and need help. I will contact you again just like this the next time I get struck by lightning which will probably be years from now”
vs - “Hello, support, today is May 1st and I need help. I will contact you again just like this on May 3rd and May 5th, May 7th, etc. forever”
These two just feel like different levels of imposition to me, even if they both derive logically from the same system (the fine print system).
2 Likes
The word “imposition” is interesting - do you see it as something outside of the ordinary use of the service? I’m assuming, for instance, you don’t feel that way about setting up goals or entering datapoints.
I’m thinking of the contrast with something like BAAS, where they explicitly agree to be in communication with you every day if that’s the amount you use the service.
Does it make a difference that your “imposition” would be in response to Beeminder’s emails asking if a derailment was legit, so you’re responding to their question rather than emailing them out of the blue?
And if you were a premium user would you feel more comfortable with the more frequent communication? Like you were paying for it rather than “freeloading”?
(thanks for entertaining all my inquiries here, by the way!)
I feel like support is part of the service Beeminder willingly provides in return for me voluntarily risking my cash. So, normally, I don’t feel bad about contacting support at all.
But, yeah, it feels like this is taking it to a whole new level, using support in a way that Beeminder didn’t intend, since they obviously intended that these (admittedly broken) features they built would do what we’re trying to do, not support.
I guess it feels like it’s outside the unstated bounds of the value-trade I have with Beeminder, which is subjective, I admit.
1 Like
Hmm. But Beeminder’s whole philosophy is
don’t waste time building something until you know for certain you need to. How do you know? Simply when you can’t keep up with doing it manually, because enough people are actually using the shell of a thing you built.
I’m curious - say you worked a job where you had Mon and Tues off. How would you feel about putting “derailments on Mon and Tues don’t count” in the fine print then, since the feature doesn’t support that?
1 Like
I think it hinges on the fact that it is a human-to-human interaction between me and somebody I know decently well. (I’ve enjoyed arguing with Danny about pointless things for enough years that you might call it friendship even though I only met him once. Not sure he feels the same way but the point is that I know it isn’t automated and I know who is doing the work.)
Edit: To be clear, Beeminder support has never refused to help me with anything or even grumbled about it. The mental hangup here is entirely generated on my side. 
2 Likes
Reasons I wish retroratcheting (and by extension autoratcheting) moved the road up or down (based on yaw) instead of to the left:
- Retroratcheting wouldn’t move breaks, allowing for a goal with planned breaks to be retroratcheted.
- Retroratcheting wouldn’t mess up weekends off.
- The weekends off feature could schedule breaks to the end of the goal, instead of just the next weekend, making it possible to see what the current plan will result in.
As it is now, if you have weekends off, only the next weekend is scheduled, presumably to reduce the damage from autoratcheting. This results in an overly-optimistic value at the end of the road, since it doesn’t take into account all the weekend breaks that will be scheduled between the current weekend and the end of the road.
This is important to me because I’ve switched to explicitly using my contract time goals as my schedule when generating date-of-completion estimates for my clients. A road that overestimates the number of hours completed at the end of the road creates overly-optimistic estimates for my clients.
3 Likes
Because this swam to the top when I happened to be browsing the forum, and some stuff caught my eyes:
Spotted this and just wanted to clarify, as someone who works in support: we cannot do that. We can only make your road the same as if you didn’t derail if you have entered the data. If you derail and it’s not legit but you can’t enter the data, the closest we can get it (at present) is a no-mercy recommit, i.e. buffer of two days.
Here I’m speaking as me, not as an employee of Beeminder: that’s not how it always works, and it is not something you should expect, I think. Many teams actually use a method whereby they first create an “MVP”, a “minimum viable product”. You roll out the barest bones version of a feature rather than wait until you have everything perfect, so that you don’t invest any more time than you have to in a version that does not actually work for your customers. I don’t think that principle is explicitly in place at Beeminder, but I think it is implicit. [Someone links later to shirk-n-turk – exactly! Perhaps I should say it is explicit, then.]
Speaking as an employee of Beeminder: we rarely hear complaints about the implementation of weekends off, and if you’re interested in that feature changing, we do need to hear from you – as in this thread. We don’t necessarily know what’s working and what isn’t, even though we are all also users of the site, because even across the whole team, we don’t share all the specialised needs and use-cases of every user. Quite frankly, I had no idea that there was any perceived problem with this feature: it works great for me, and I’ve never run up against the incompatibility issue.
As long as it remains in your fine print. I’m not sure where you got the idea that there was a statute of limitations on your fine print or on support helping you, so as support czar (whips out the correct hat and settles it on their head) I’d love to hear about why you thought we wouldn’t honour that. If there’s something in our docs that sounds kind of like that, I’d like to get the red pen out!
If lots of people took that solution, we’d probably take it as a sign to change how weekends off work to accommodate that way of using the site. 
Or we’d increase support capacity, or we’ll talk with people about personalised solutions, or whatever ends up being the right thing to do. That’s for us to worry about!
I work the same hours each and every day, regardless of weekends or most holidays, and other workerbees also pitch in on weekends and holidays as well. (By choice, before anyone worries about it!) Weekend derailments make no difference in that sense.
5 Likes
If this is the case then I think everything I wrote in the post a What are the technical reasons for the incompatibility between autoratcheting and weekends off? - #7 by drtall stands? i.e. the bogus derail does have an effect on the overall rate of the road if there’s always a buffer inserted.
I think this philosophy is the root cause of a lot of needless technical debt in the software industry. Especially in medium sized companies where they (rightly) took that philosophy when designing their initial product but then keep using the philosophy to bolt immature things on to a now mature ecosystem. I agree that it’s a common practice but I don’t know if it produces good results down the road.
My understanding of shirk-n-turk is that it’s about choosing a different implementation (code vs humans), not lowering the bar on correctness. I thought the philosophy was all about not compromising correctness in a rush to automate. Here we have the opposite, where it is automated but it’s done incorrectly.
I usually assume that the Beeminder employee base has heard quite enough from me. Regarding this specific bug, I emailed about this in Nov 2017 and I’ve been involved in various discussions: Why does retroratcheting change scheduled breaks? - #5 by drtall , Precommitting to data points - #2 by insti , Triangular beeminding for tracking alcohol consumption - #38 by drtall , Detecting auto-retroratchet in the API? - #4 by drtall . I’ve probably talked about it elsewhere that I’m failing to pull up in a search too.
Frankly this class of bug is one of the original old chestnut bugs of Beeminder which has worn me down to the point that I don’t talk about it much unless prompted.
No, I 100% believe you would honor it. I just think I would feel weird about it, as I’ve tried to explain above.
I’m game to try but if the very first quote is right then it won’t really help I think? I mean if there’s not going to ultimately be a guarantee that the road has a certain average rate.
3 Likes
I think you’re correct in that reading of the situation, and I do think your participation in the various threads, etc, are an ample sign that you personally have problems with the current implementation. But it’s nonetheless true that I’ve worked for Beeminder a year and this thread was my first real notion that there was a problem here.
My feeling is that the way to make us feel a need to prioritise this in any way would be to turn on autoratchet and weekends off, and then yell for help every time it goes wrong, rather than create a fine print exception. We would certainly put the road right in that case. Not using the features tells the team instead that you don’t need them, rather than that you want them but they need to be fixed.
Potentially the answer in the end would be “those two features are irreconcilable and you will get a message saying so if you try to turn both on” – I’m not promising a fix, here, and having to contact support all the time wouldn’t be frictionless!
Probably truer than my offhand “yes that’s it”, yes; I was thinking of something else, really. I’m not really the right person to argue about the value of MVPs, since I only know about the concept from elsewhere, but I don’t think they necessarily mean technical debt. It can mean what it says: a minimum viable product, something on which other things can be built or just something that allows feedback to be gathered. If the answer to the MVP is “this doesn’t work with x and y”, there isn’t a vast edifice based on assumptions of what people want built on top of it already; it can be scrapped and a better solution built. If the MVP works for 99% of people, the answer is that the MVP was sufficient.
(I am mostly speaking personally here and when I am speaking as a Beeminder employee, it’s just to explain what support would do. That’s my wheelhouse, and I have little input in what gets prioritised or fixed.)
4 Likes
Oh man, I had NO idea that beeminder wasn’t aware that the autoratcheting/weekends off incompatibility was a real problem 
I’ve definitely made at least a couple forum posts asking for ways to work around it, and have complained to support in the past. But as previously mentioned, I usually figure that any bug THAT old is on the “won’t fix” pile.
But yes, it’s a serious problem for me. It’s so serious that I have created my own, incredibly complex workaround: I don’t use weekends off, instead I have IFTTT feed dummy data to each goal on weekend days. This has the obvious downsides of making things more complex – every goal needs its own IFTTT – and it also it makes the data wrong. Plus, every time I change my slope I have to update the IFTTT recipe. But it works, so I don’t complain. I suspect that’s part of why you don’t hear people complain about weekends off – because those of us who need it have worked around it.
3 Likes