It’s been over a year, and it seemed like a high priority. I feel like I’ve repeatedly heard about various other things that “we’ll do that after YBHP” or “that won’t be necessary after YHBP”.
So, is it:
much harder than it seems to me, as someone who hasn’t edited Beeminder’s code, to be?
not actually as high a priority as I think?
no one is really working on Beeminder’s code right now?
uncertainty / disagreements over how some aspect of it should behave / look to users?
uncertainty / disagreement over the technical implementation of it?
uncertainty about how to launch it / communicate it to users?
something else I didn’t think of?
And in any case, is there anything I (or other interested people), as Beeminder users, can reasonably do to speed things along?
Taking a wild guess: send cookies to @bee? Oh, reasonably, nvm then
But this brings me to the problem at hand:
Aside from @dreev@bee is the only other full time employee and AFAIK the only full time developer on it. And there is only one @bee.
Taking an even wilder guess: The Beeminder code is a curated selection of hacks piled on top of each other (unlike any other software project ):
That post is from 2013 so there is a very good chance I am totally wrong and the code quality has improved greatly making changes possible again without having to sacrifice a kitten or your firstborn child.
However the code is a mixture of Mathematica, Ruby, Python and Javascript if my recollection of strange Beeminder facts serves me well. None of those languages are known for their static typing and whilst legend has it that there exist people who can be productive in dynamically typed languages I do not count myself amongst them.
Of particular impossibility in such code is refactoring for the refactoring tool has no good knowledge of the types of things and at the end of the day you gotta do everything by hand. And this really slows down any kind of change you want to introduce.
So with this and the cultural pessimism I have cultivated as developer over the past many years I expect that @bee is sitting in front of some many monitors filled with vim windows drowning in JS code that tries very hard to avoid change at all cost.
Please correct me if I’m wrong. After all, this is just me sitting on the other side of the globe rambling and piecing together random bits of information and making up the rest so there you go
The fundamental observation behind YBHP is that the core concept of Beeminder’s original implementation was a mistake[1]. I would think that this has tendrils that reach into every part of the code and user experience. Not to mention a lot of the copy on the website and the bulk of all blog posts.
The thing I’m shocked about isn’t that it’s not done, it’s that they agreed to actually try to do it.
[1] I mean this in the technical sense with the benefit of hindsight. Not from the product sense, because it’s clear that the notion of lanes and autowidening and such were all instrumental to getting Beeminder off the ground.
Or, to put it another way, at a prior job of mine which was a company with hundreds of engineers, they re-wrote the main guts of the “brain” of the product. This was a major thing that the CTO cared about but it still took roughly 2 years, involved running both systems in parallel for many months, and was widely considered to be a miracle when it was successfully done.
I happen to think this particular case should be an exception, because the thing Beeminder did instead (lanes) is actually a source of massive amounts of complexity that YBHP allows them to simply delete. Can’t really know unless someone from Beeminder answers, though.
i’m extremely heart-warmed by @drtall’s apologia but agree with @kenoubi pretty much completely. i even almost agree with the sorta implied “is anyone even working on the code??”. i mean, we have been, all day every day – and you can see the blow-by-blow at Beeminder Changelog (well, that’s the user-visible tip of the iceberg – plenty of those things, like what shows up user-visibly as crisper svg graphs (whoop-dee-do) is part of a massive undertaking to switch from python/matplotlib to javascript/D3 (and that’s in fact part of YBHP – we meant for YBHP to be a prereq for that but flipped it around) anyway…) where was i? oh yeah, we have not been smart about triage and project management, etc, and that’s a big reason we have @mary now!
hugely appreciate little kicks in the butt like this!
answering the specific questions:
kind of, and there’s some truth in @drtall’s characterization. it touches freaking everything.
well, also kind of. i personally view it as high priority but CEO’ing generally has taken precedence and the way YBHP spans the rails code and beebrain (the graphing/stats) it kind of needs both @bee and i heads down on it. this is another thing that @mary is helping with as she’s now COO/CFO.
yes, even just for the death-to-auto-widening piece, for which we have a sprawling confusing blog post draft…
i guess but i mostly don’t want to justify our slowness. it’s really not ok and i’m thinking about how best to hard-commit to getting this thing out the door. obviously this didn’t quite work: http://dreev.commits.to/deploy_YBHP/by/this_summer (that “this summer” is, gulp, last summer!)
i mean, we have been, all day every day – and you can see the blow-by-blow at