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.
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. 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.
 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.
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!)