Hacker Newsnew | comments | show | ask | jobs | submit login

In case anyone didn't see it down at the bottom, this comment was left on the post:

  Ryan (& Everyone Else) –

  My name is Mike Vernal, and I manage the engineering team for Facebook
  Platform.

  I understand and am legitimately sorry for the frustration you guys are
  experiencing.

  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,
  and maintain.

  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
  mvernal@facebook.com.

  Thanks,

  -mike



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

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!

-----


Its great that they're trying to simplify it and use standards, its not so great that the way they've been getting there is to simply switch old things off without notice and not document or adequately announce the new ways of doing things before they launch.

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.

-----


Very interesting. As an FB developer, some of the bugs they introduce (and re-introduce) are baffling. Their QA process always appears non-existant.

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.

-----


I worked at a company developing proprietary image processing SDKs (more like libraries) for .NET/ActiveX. We actually had very extensive QA, probably >100% code coverage (at least 1 test for most code paths) in unit and functional tests, but it's really difficult to predict how customers are going to use your product.

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

-----




Applications are open for YC Winter 2016

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | DMCA | Apply to YC | Contact

Search: