Today, I made it through the day, working on my ToDo list of what I thought needed to be done today, in between the random interrupts and distractions that constantly surprise us all. Revisiting my ToDo list several times during the day helps keep me on track. If all goes well, by the end of the day, I’ve made progress on most of my ToDo list, *and* managed to handle the various interrupts. Otherwise, sometimes I feel like my busy day was all unfocused churn; busy but not productive - the all-too-familiar cry of “I did lots today, but got nothing done”!
So, thats today. But does today’s work fit in with tomorrow’s work? And the day after? And the day after that? For me, making a mental plan of the week, and then trying to guesstimate what can be done before what is tricky. Easy right?
Does this week’s work fit with next week’s work? And the week after?
Does this month fit with next month?
Does this quarter fit with next quarter?
In theory, if we plot where we are today, across four quarterly goals, we should land exactly at the pre-decided goals for 2008, plotted in a perfectly straight line from start to finish. In theory. Heh. Yeah, right. Not surprisingly, as the time span lengthens, it all gets dizzyingly complex really, really, quickly. A quick scan of the business section of the local bookshop proves how common this problem is. A project is more complex then expected, and takes longer to do. The cross dependencies with other people’s work grows. The risks of unexpected surprises grows. People change. None of those goals exist yet. You can try your hardest to reduce the variables, but in reality its impossible to predict a bunch of things over the next 12 months, so its all really a giant guessing game.
Despite all the possible pitfalls, distractions and disclaimers, the idea here is to have some idea of what we’re all aiming towards. Its makes planned work in a given quarter make sense, compared to the quarters before and after. Also, we break big projects down into small chunks, but at some point, we need to expect all the chunks to come together making a completed big project. Where does that happen? Here. To stop people freaking out about the scale of it all, John & Mitchell asked that we tell it all as a story: pretend its the end of 2008, and we’re looking back over the entire year, telling a story of what we did. Here is the Build story.
We might not quite hit everything, despite the best of planning. Or we might hit it on the nail, but by taking a completely different path. Or miss something completely, and nail some unexpected last-minute project instead. Who knows. But at least, this forced us to stop, look up, and think a little about the bigger picture. All good, imho.
Let us know what you think?!
tc
John.
=====
[snip]
Well, 2008 was quite a amazing year.
From a tactical perspective, we rolled out automation on all the remaining FF and TB branches, shipped the FF3 release, expanded the scope of the automation to cover all of the random last-minute items that crop up, expanded the TB automation to also include Lightning, kept the TB releases going until we transitioned them over to a self-sufficient MailCo, worked through the FF Mercurial transition, and did more firedrill security releases than we care to count. We still have lots to do in terms of improving turnaround time, integration with test automation, performance automation, etc, but still… not bad.
But from a strategic perspective, the highlight of the year was how we did all that *and* at the same time, morphed from being a burn-out-and-replace group into a sustainable, humane, efficient team proud of what we’ve proven we can do. That change has finally given us the time to catch our breath, look beyond the next firedrill deadline, and realize there’s something special about our situation.
Frequently, in this industry, the Build group is an afterthought, hidden deep in the bowels of a software organization, somehow treated differently from Dev, QA and IT. Opaque to the rest of the company, the rest of the world and even worse, the Build groups in other companies. This means every Build group is forced to reinvent the wheel, learning from their own mistakes as they go along, rather then being able to learn from the mistakes/successes of others. The few people talking publicly in this area are typically selling software/consulting/books.
We however are in a unique situation. We have a rare ability to let people see how Build&Release works. A transparent Build & Release infrastructure is a unique luxury we have, which most people simply can not have. By adding Build&Release to our open source projects, like browser/email/calendar, we can build up the pool of knowledge in this industry by showing other Build groups what worked for us, as well as what didnt work. We stay impartial, because we’re not selling anything! We keep things practical because we use our work in production - we’re not just writing theoretical whitepapers. Heck, people might even decide to use our work as their open-source-build-platform! We can make Mozilla a public case study of how to make things better… or at least, how to not make things worse!
[snip]