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
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”.
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.
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?
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.
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.
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.
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 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.)
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.
(FWIW, on the sidethread of “what can we comfortably ask support to do”, and also on the sidethread of “making support do a lot of work is a great way to push a feature forward”, I currently – and on the explicit advice of support! – ask support to schedule all my all-goal breaks, because I am both confused by the break format, and think having to set breaks in a dozen goals is hellish.)
I sort of envisioned that you had a whiteboard full of my complaints on it at the Beehive. Just kidding, what you said makes sense.
Unfortunately I can’t because the features are premium, so I can’t use them as-is. And I’m not willing to buy premium given the state of these two features. I think your suggestion would work for free features, but there’s a circular dependency when considering premium features.
Put another way, your next paragraph is my fear:
Given perfect data I would agree with you, but I think the gatekeeping thing discussed above as well as https://blog.beeminder.com/cockroach/ make it difficult to have confidence that a feature is actually being adopted and used as you expect? I’m genuinely curious 1) what fraction of premium users with access to weekends off use it; 2) what fraction of all Beeminder users would use weekends off if they could.