Ryan (& Everyone Else) –
My name is Mike Vernal, and I manage the engineering team for Facebook
I understand and am legitimately sorry for the frustration you guys are
I think there were three themes in this post — frequency of change, bugs,
and documentation. I wanted to give you some more context on all three
points, not as a way of excusing the problems you’ve had but as a way of
adding some additional context.
Over the past year or so, we’ve been pushing to simplify and standardize
our development platform as much as possible, to address some of the root
causes of the issues you point out here. For instance, we’ve been trying
to move from FBML to IFrames over the past year because we think that
IFrames are both a lot simpler to develop for and a lot simpler to
maintain because they’re based on standard web technologies. We’ve also
been moving towards simpler ways of integrating Facebook context
(e.g., iframe-based social plugins) because they’re easier to use, debug,
Our end goal is to have a technology stack that is simple and
standards-based, because we believe that’s actually the best way to
address many of the issues you raise here.
In terms of bugs, you’re right — we haven’t been doing a good enough job
here. We’re working on this. We’re triaging bugs on a daily basis and
working through the bug backlog. We’re continually adding more automated
unit + functional tests to help prevent regressions and issues in the
first place. And we’re working on our communication processes — the way
the system works today, we actually copy verified bugs from Bugzilla into
an internal bug tracking system, and we then use that internal bug
tracking system to drive bugs to resolution. We don’t do a good enough
job of communicating back to the Bugzilla bug the internal status and when
we actually push a fix, which we’re working on.
In terms of documentation, again, you’re right. We’re building up a team
and focusing on this as well.
That said, actions speak louder than words. If you don’t see meaningful
improvement by the end of October, please let me know. My email is
What an utter waste of effort! For more time spent doing grunt work, you give slower and less complete feedback to your customers (platform developers in this case). There may be some information they don't want in a public tracker, but I'm betting it's:
- a lot less information than they think; and
- much easier to manage in a different way, as opposed to maintaining two bug databases!
Honestly, I get it but the damage has been done. The hype window surrounding the facebook platform has passed and their developer outreach effort is too little too late.
I'd like to believe him, but would have to see it first. We often file bugs that sit there forever, and some parts of their platform break on a weekly cycle, if not more often.
For this reason, newer employees had to do a cycle of QA/support/dev, where you found out that there would always be one customer whose entire use case was the one case you didn't test for, and that makes your toolkit fail horribly. I'm not excusing these bugs, and Facebook is certainly a more complex platform to build on top of, but I can certainly see how a QA team could be working nonstop and appearing to accomplish nothing.
(Also note that since leaving this job better testing tools have come out/become more popular. The Ruby community especially is very oriented toward automating "mutate this test until it fails".)