Main menu:

Site search

Categories

Archive

Tales of a Project Leader I: The Glue Person

We did a debrief for the JägerMonkey project a while back, and I had been meaning to write up the results as a sort of definitive history with all the lessons learned, but I never seemed to find the time. So, instead, I’ll try to write a series of blog posts on the high points, which hopefully will be easier to get started on, and also maybe more useful.

The Backstory. Here’s a brief summary of the project, to provide context: In late 2009, we had wrapped up development work on Firefox 3.6; I had just come off the CrashKill project, where I had fixed a bunch of the most common JavaScript engine crashes from the crash reporter.

About a year before, Google had released V8, and Apple had released SquirrelFish Extreme (now called Nitro). Both engines used an untyped [1] function compiler [2] with inline caches [3]. Both of them started out with good speed, and had very good speed by the end of 2009. Opera also had very fast JS with its Carakan engine. SpiderMonkey was seriously falling behind on SunSpider and the V8 benchmarks–we knew we had to do something big to catch up.

[1] I use “untyped compiler” to mean a compiler that works on boxed any-type values; a “typed compiler” compiles code specialized to a certain set of types. I used to say “type-specializing compiler” and “basic compiler”, but I always found the former unwieldy and the latter vague.

[2] “Function compiler” means a compiler that compiles a function at a time, in contrast to the TraceMonkey trace compiler, which compiles a linear code trace at a time.

[3] Inline caching is one of the most important optimizations in a JS engine. See cdleary’s blog for much more.

The obvious something big was an “untyped per-function compiler with inline caches.” So we made the decision to do it, formed an initial team consisting of me, David Anderson, and Luke Wagner, and chose the name. Our goal was performance competitive with V8, Nitro, and Opera. We gave an initial estimate, which was just a guess, of 9 months.

And we basically did it. We landed JägerMonkey to the TraceMonkey repo on August 31. Testing on that repo turned up a few more problems, but JägerMonkey went on to mozilla-central 2 weeks later. (There was also some fallout involving compartments and Firebug support that had to be sorted out around the end of the year. More about that later.) We also hit our (fuzzy) target on benchmark scores: ahead of V8 and Safari on SunSpider by a small margin (with IE ahead of us by a small margin), and a solid score on the V8 benchmarks, second only to V8, and pretty close to them until Crankshaft came out the next year. I think it’s fair to say that with a 10% error margin, we did just what we said we would way back in December.

We also got a cool poster, t-shirts, and had Firefox playing Super Mario at 58 fps.

My role was project leader. By that, I mean simply that I considered myself responsible for making sure the project as a whole was successful. That included architecture, dividing work, spotting issues, recruiting help, selecting optimizations, arranging infrastructure, and critiquing t-shirt design.

I also did some coding, although it wasn’t my primary task and I didn’t have long periods of uninterrupted time to work on big features. Toward the beginning, when the project was smaller and things were quieter, I did implement ICs for the first version of the compiler.

The next big patch of coding I did was when Luke was finishing fatvals (the new jsval format). He had designed the new C++ classes for the values and did most of the engine adaptations. But there were a bunch of bugs that needed to be fixed before landing, and fatvals was about to be the bottleneck: the new compiler depended on them. So I jumped in and fixed a bunch of small bugs in fatvals and got that landed.

Later, when the compiler was getting close, and landing it was the next big step, I jumped in there to fix a bunch of bugs and get that ready. Also during that time, I was doing daily merges from the Tracemonkey repo (which was the main repo for JS development) to JM, so that we would catch merge fallout fast and stay sync’d and ready to land.

From my project leader point of view, as needed I deployed myself as an extra developer to speed things along. In the debrief, Luke called this the “glue person” role. He said having a glue person allowed everyone else to get into the zone and do lots of design work and big blocks of coding–everyone else on the project doesn’t have to worry about random bugs and and other small technical issues because the glue person picks them all up.

It’s similar to the “fix problems and remove obstacles” aspect of being a project manager, except it’s fully technical: solving whatever random coding problem that is necessary right now, but would be a distraction to everyone else. And it fits well with doing the rest of project management, because while it’s hard to do a big design project when you have to step away to do something else frequently, small bugs can be squeezed in pretty easily.

I suppose not all developers would jump at the chance to be the glue person, because it looks like grunt work, but I didn’t mind too much: it’s a great contribution to the overall success of the project, and it’s a nice favor to the rest of the team.

Comments

Comment from Martin
Time: August 1, 2011, 12:03 am

I don’t think the project leader should ever be any kind of “glue person”. We do scrum, and i think the project leader should have a scrum masters role, making sure the team can work and getting stones out of their way.
I know it’s hard not to take part in coding or bug-fixing in these kind of projects (maybe bugfixing in a late phase is the only work a project leader could do without leaving his role) but teams need leader with an outside view.