Ahead of the Release Curve IV: Defining the Curve
In case you’ve only ever read this “blahg” via its RSS feed, the tagline reads “What does a Build Engineer do all day, anyway?”
I’ve been thinking a lot lately about the answer to that question.
When I think about what my answer actually is, day-in-day-out—doing builds, triaging broken builds, restarting automatic builds, respinning builds, making sure there’s enough space for builds, signing builds, staging builds, getting new places for people to get builds, fighting fires on the machines the builds are created on, making sure the builds… well… you get the idea—it all seems somewhat… repetitious.
(And the more I look back at that, actually somewhat depressing.)
But even though we, Rob, Coop, TR, and I, do work on those things, I’m pretty sure we all think about other things, especially the fourth or fifth time in a day you’ve logged into the same Tinderbox to kick it.
Part of this recent introspection about what we work on, what we want to work on, and what we should work on was prompted by a question Schrep posed to me a week or so ago: we had just finished a company-wide discussion of goals and missions and he asked off the cuff what the Build Team’s manifesto would be, if we had one.
Something along the lines of “What should we be thinking about in the day-to-day that prompts us to work on things that have perceptible, positive impact, not only for ourselves, but for everyone else?”
There are the obvious ones: doing builds, triaging broken builds, restarting… well… you know… but isn’t there more than that?
Should there be more than that?
If you’ve ever talked to Rhelmer or I right after a release, our reaction to the mere mention of the word “build” implies that there should be.
In trying to tackle the answer, the only thing I could think of was make a list. As I sat there, trying to brainstorm what the list should include, I found myself jotting down the things I think about all day (and sometimes worry about at night). Some of them had that dirty, five-letter b-word… but a surprising (to me) number had nothing to do with that.
As I sit here, counting the thirty-plus items on my laundry list, I wonder if anyone would be surprised that someone thinks about these aspects of a software project that stare back at me. Does anyone really care what the number of old builds we store says about us?
Or why bumping versions is a big deal?
Or what the deal with centralized build data stores is?
Ok, so maybe people wouldn’t be surprised.
But, still I wonder. I’ve been in situations where I’ve been asked “Hey, can you guys do X?” When my answer isn’t what they expect, it sometimes prompts what can be an involved conversation about why the answer wasn’t a simple and immediate “Yes.”
I think such conversations are useful in the long run.
But I can’t help think if there were a good answer to the question my “blahg’s” tagline poses, then maybe some of my weird answers to questions would make more sense to others sooner.
As a bonus, if I could distill the common themes behind those day-to-day answers, I might just have the makings of a manifesto that would at least frame our discussion for what unique qualities we bring to the “MozillaVerse” (or are the cool kids calling it “Mozillasphere” these days?)
Think of it as an attempt at a JoelOnSoftware knockoff, except… without all that annoying credibility and pestering about having created-Visual-Basic-for-Applications-but- before-it-was-called-that-because-I-only-worked-on-Excel-at-the-time getting in the way.
On the downside, I will admit: it is highly likely there will be fewer treatises on the speed of duck-typing.