The Snappy name will be retired in favor of Performance: we will be expanding our meta scope beyond desktop Firefox responsiveness.
I think as a result of Snappy, Firefox is in a much happier performance place now. There are a big wins remaining, but we have tools and ideas on how to get there. We’ve come a long way from “how to make Firefox feel fast?” discussions in late 2011.
Snappy has been a tricky meta-project because work has to happen across teams. While my Performance team has an exclusive commitment to performance, other teams have to context-switch between feature-work, platform-work, performance, etc. There are also team culture differences on internal vs external communication, planning, etc.
Some of the projects are quite hard and require specialized expertise. This meant that we’d make a bunch of progress on a project (eg breakpad profiler backend) only to realize that we are blocked on someone we didn’t loop into the project right away (eg Ted). Ideally we will minimize chances of surprises like this in the future.
Until recently my solution was to deal with this as a manager. I’d sync up with relevant managers about Snappy needs and try to get some Snappy bugs onto relevant team’s todo. This has worked out ok, but there were a few too many instances of unexpected delays due to shifting team priorities, miscommunication, general lag. My conclusion is that at a developer-driven organization like Mozilla heavy manager involvement on Snappy-type projects is a sign that we are doing it wrong. Developers should be adding performance goals to their team’s agenda.
Last week we came up with a more developer-centric way to do performance work. I’ll still be around making sure things are moving forward, but from now one I’d like to see developers drive planning & coordination on a per-project basis. I’ll introduce individual projects + their respective blogs as they start in the next couple of weeks.
Irving Reid (addon-manager startup performance lead) summed up key mechanics of the new approach in an email. Thanks, Irving.
Irving’s Summary
Coming out of the Snappy work week, we decided to try and make performance projects a little more structured than they have been in the past; see Lawrence’s post for a summary.
While not mentioned in Lawrence’s blog, one of the things Taras (if I recall correctly) suggested was to have a project kick-off meeting to get rough agreement on scope, responsibilities, and how we’re going to track progress. If everyone is happy with settling those questions over email, we can; I think we lose a little by not getting a chance to see and hear each other directly, but it is rather painful to get that scheduled in the current circumstances.
In any case I wasn’t planning on delaying work until after the meeting could happen; it’s more about getting things as clear as we can, as early as we can.
The current plan is for Felipe and I to do the patches, with me handling coordination and progress tracking as well. Everybody else is involved to make sure we’re going in the right direction, and help us over roadblocks.
The progress tracking technique the Snappy team settled on last week was a combination of daily one-line updates using the status bot in the #perf channel, and a blog post every two weeks summarizing overall progress. I’ll do the blog posts; depending on how things go I may do them weekly instead of biweekly.
]]>
