Geoff here - I am a product unit manager at the MacBU, and lead for the design and engineering of Office for Mac. Here are a few thoughts on the year in review.
First, Macworld 2008 was a great place to kick the year off with a big launch, as we released Office 2008 after an intensive four year development cycle, including migrating our product line to Universal applications and building in support for the Open XML file formats. New award-winning eco-friendly packaging in hand, we got to sit down with ever-ebullient Macworld attendees, geeks, colleagues and press to talk about the newly released suite. A great reminder of the diversity out there with Mac users, all nationalities and all ages – I particularly remember our interview with the Teen Press of my former hometown’s Santa Barbara Middle School (SBMS Teen Press on Macworld.) There was A Day at the Office and a little help celebrating the metacognitive Macness of it all from none other than the legendary Devo.
Office 2008 included many new painstakingly crafted features, more than are easy to list – a year after launch a few that I’m still commonly pointing out to people because I know they’ll get hooked on them are Publishing Layout View, SmartArt, and Ledger Sheets.
Since Office 2008 launched in January, we’ve been highly focused on developing and releasing continuous updates, with a focus on monitoring and improving the stability and performance of the product. Just in our Office 12.1.2 update for example, Word’s launch time improved by as much as 30% and Excel’s calculation performance by as much as 50% (some calc-heavy test cases saw even more improvement – the result of floating point math optimizations.)
We’re now well into development of that next major release. We passed our milestone 2 checkpoint in November. The all hands mentioned by Eric included live demos of basic VB scripts running Intel-native in a test harness (no, not near ready for release) along with a long queue of other demos from all three development sites, some of which we’ll be sharing sooner rather than later.
The engineering team has grown, with great veterans in key roles and some great new hires. Earlier in the year as we geared up for new development to start in earnest, we instituted some significant changes to our development practices, with a stronger focus on feature crews (tight coordination of developers, testers and program managers to drive each feature to shipping quality early) and stepping up our approach in such areas as architectural reviews and user experience focus. We’re now moving ahead pretty smoothly with the new system in place and we’re generally focused on execution, meaning getting the new product built, with efficiency and high upfront quality (that is, when we’re not focused on creativity.)
Some deeper investments in the Mac Office codebase are underway, including more aggressive conversion to Cocoa, building on the great Carbon-Cocoa interop foundations that are now in place in Office 2008 and Leopard as well as some of the progress we’ve made in better factoring model and view under the hood. On the compatibility front, expanded portions of Word and Exel core code have been fully re-ported – some promising progress in a relatively short time period.
Meanwhile we still have many crews working on straight up new features and functionality, either underway or already exited (and on stage for the aforementioned demos.) We really look forward to sharing more of our new work with you in the coming year.
Please keep the feedback coming, and let us know if there are topics you’d like us to address here at Mac Mojo in 2009. If you’re in the city, stop by the booth or the lounge at Macworld and say hello (or… whatever you have in mind) – we’ll see you there.
Best wishes on the new year and happy holidays to you and yours,
Geoff
I usually don’t tell people my job title when they ask what I do. Something about “Program Manager” just doesn’t seem to resonate with many people outside of industries that use that title, or Microsoft in particular. If pressed, I usually fall back on less specific phrases like “Software Engineer” or my personal favorite “I help make Mac software for Microsoft.” The latter description seems to evoke the most colorful reactions of the bunch, and it’s probably the most accessible one-phrase description that I can offer to those outside my chosen profession, but it’s also perhaps the least specific job description that I have for myself.
So what does it mean to be a Program Manager in the Macintosh Business Unit?
First off, the word “manager” in my job title is a bit of a red herring. Unlike my manager, I don’t manage anybody except sometimes myself. That said, I do manage multiple interdependent projects (which, in my case, generally include various features of Office for Mac), and I do make prioritization and resource allocation decisions, so taken together that does approach at least one definition of program management.
I am a software engineer by background and I practice program management as a member of the engineering team that produces Office for Mac. Part of my role on that team is to be accountable for things getting done. (Again, “things” here are usually various features of Office for Mac.) I don’t always engineer those things myself – we have Software Development Engineers who do that for software features – but that’s not to say that I don’t do anything at all (though some of our Software Development Engineers might say that… purely in jest, or so they say). I don’t write the code (anymore), but I do help ensure the right code is written.
A big part of what I do is information synthesis. We’ve got business people and senior management who tell me where they want our products to be, engineers who tell me where they can take our product to, and customers who, well… who sometimes frankly just tell me where they think our product can go, and my job is to synthesize all that input and create a single output which is a cohesive vision for where our product will actually be… and then it’s my job to take it there. This is probably the part of my job that I find both the most challenging and the most rewarding.
I find that an analogy to the role of a film producer (and arguably “line producer” in particular) can also be helpful in describing the role of the Program Manager in the Macintosh Business Unit. Just as a film producer creates the conditions in which a film can be successfully made, so too do I in my role as Program Manager help create the conditions in which Office for Mac is produced. Specific activities that I perform in this capacity include understanding our customer needs and designing software experiences that address those needs, as well as ensuring internal resources and juggling priorities to enable those experiences can be effectively engineered.
I’ll give an example to help illustrate a bit of what I do.
There was a point last year at which it became clear that we would not be able to include a ‘selection’ object in the AppleScript dictionary for PowerPoint 2008. If you are one of the many Office for Mac customers who care about the PowerPoint AppleScript dictionary then a ‘selection’ object is very likely to be one of your highest concerns: It is quite literally impossible to write scripts that operate on the presentation document’s current selection without such an object; entire categories of potentially useful, time-saving, or even mission-critical scripts would not be possible.
I lobbied hard to get an AppleScript ‘selection’ object done for PowerPoint 2008, but in the end I had to agree that it really did not make sense to complete that work at that time. But we knew that this feature would be important to important customers and so I was able to generate support for a plan where we would complete the AppleScript ‘selection’ work for PowerPoint immediately after Office 2008 was released.
Even then, AppleScript ‘selection’ proved to be large chunk of effort to complete. We knew it would be, so I worked with stakeholders to prioritize the subset of this feature that would be most important to customers who need this functionality. We completed this subset and delivered it to customers in Office for Mac version 12.1.0 just a few months after Office 2008 for Mac first released.
If you have Office 2008 for Mac today and you keep it up to date with the latest updates then you can script PowerPoint using a reasonably full-featured ‘selection’ object in AppleScript. We intend to finish out the rest of the ‘selection’ implementation in a later release, but my team and I are confident that the AppleScript dictionary available with 12.1.0 will suffice for a vast majority of interested customers. If that’s not your experience, let me know!
So what does it mean to be a Program Manager in the Macintosh Business Unit? Well, in my case it means that I love my job! For real. I get to work with some of the best, brightest, and most experienced Mac developers on the planet and together we get to define and deliver software that millions of people use and rely on every day. I think that’s a pretty cool job description.
Last Wednesday was our general "ZBB" target for the Office 2008 project, a major milestone on the road to release and something we've been pushing hard for over the past several months. We saw some fantastic surging by the development team to clear out backlogged product issues late into Wednesday night. Thursday, we sat down to review project status and metrics in depth, and to hear all teams report out on their plans and readiness to lock down for release. The bottom line takeaway that you may be most interested in: all teams have confirmed readiness to ship on the current schedule. As previously announced, this means RTM in December and general availability starting on January 15th (by region).
ZBB what? This stands for Zero Bug Bounce, or as alternately phrased, Zero Bug Backlog. At this point we have been logging, tracking and verifying all changes to the product in great detail for some time -- collectively we refer to this list of logged issues as the "bug list", though in reality it includes a variety of issues including bug/defect reports, tracking records for artwork or content, usability improvements, numerous suggestions (submitted by team members or beta testers, or representing customer or partner requests), and various other categories of issues. The ZBB milestone is defined as the date across which we will no longer carry logged product issues that are more than one week old. Hence, the "backlog" of issues has been cleared out, and all older pending decisions on what we are or are not going to change before we ship have been made. It also means that the developers have "caught up" or "outpaced" the incoming find rate of our test efforts.
From here on out, the focus is increasingly on lock down. We are testing for defects literally around the clock, using a variety of methods ranging from automated efforts such as "massive file testing" to targeted manual test passes and "ad hoc" free testing. We also continue to log and fix significant issues found in private beta testing. At this point we remain busy fixing bugs as they are found (any one of our millions of lines of code could be the source of a defect,) but there will now be increased scrutiny on making changes -- i.e., is there sufficient customer need to justify a proposed code change given the associated risk of regression (the outside chance that making a given change causes a new and potentially more severe problem.) Stabilizing the product for release requires conscious commitment to slowing and eventually stopping the changes we're making to it, and as a result we now start reviewing all proposed changes daily in "triage".
I'd like to congratulate and thank everyone on the product team for an amazing effort on ZBB -- our developers, testers and program managers have all done incredible work. I'd also like to thank every other person who has helped in the creation of Office 2008: planners, researchers, designers, artists, writers, editors, builders, product managers, recruiters, HR generalists, international teams, MVPs, beta testers, partners, vendors, contractors, our many friends at Apple, partners across Microsoft, and many others have all helped us get this far. Finally, a very sincere special thanks to all of our families and friends for their support during this push.
Collectively we've made nearly four years worth of heavy investment in modernization, improvements and features in Mac Office. We look forward to continuing to share more about the new suite here on the blog and out in the world straight through RTM and into next year. But, as folks like to say, at this stage of the project the most important feature is shipping.
We're getting more excited about that feature every day.
In case you haven't heard, Silverlight is a new rich internet application platform developed by Microsoft with support on both Windows and Macintosh systems. It's pretty awesome. The Silverlight demos presented during the Mix 07 conference keynote were simply out of this world, and featured the cross-platform experience on Mac (or, depending on your perspective, the cross-platform experience on Windows) quite nicely.
Developers can use XAML (a subset of the same XML-based vector graphics markup language used by Windows Presentation Foundation on Vista) in the browser, and bind XAML controls through the DOM to either Javascript or the .NET Framework core components, the latter of which was brought over to Mac to help make this happen. That's right; I said .NET Framework on Mac. Exciting? You bet.
Too geeky for you? How about streaming Windows Media audio and video, supported by Microsoft, including HD video up to 720p? Check out theseMix07demos (I'm personally a major fan of Top Banana) and you'll start to get a sense of the kinds of exciting rich internet experiences that Silverlight helps to enable.
Not geeky enough for you? What about dynamic language runtime support, so you can implement all your code-behind in Ruby, Python, or what have you? How about designers and developers working together with seamlessly integrated workflows to help each other deliver striking content with killer functionality behind the scenes? How about the power and performance of the core .NET Framework helping to deliver both software and services online, across browsers, and across platforms? How about 4 GB of free Microsoft-hosted video? How cool is that?
Did I mention that Silverlight is supported in both Safari and Firefox browsers on the Mac? Okay, I admit, I'm feeling just a little bit of Silverlight excitement.
So, that's all good and exciting, but what does Silverlight have to do with MacBU anyways? Well, in a sense, not much: Silverlight is not a MacBU effort. Why not, you ask? Well, as you probably know, MacBU has never been the only source within Microsoft for software on the Mac. We certainly are the center of gravity for exciting Mac-specific experiences at Microsoft, but Silverlight (which is really about exciting cross-platform experiences) doesn't really fit that "Mac-specific" charter. But we're certainly excited to have Silverlight join us here on this exciting platform that we call the Mac.
As previously announced, and as indicated by the lower frequency in blogcasting here, everyone at MacBU is exceedingly busy completing Office 2008, which is on track for release later this year. This work is our primary focus, and is the largest undertaking in our ten year history as an independent team. We are developing the product for versions beyond 2008 with broad investment in native Mac OS X architecture as well as adoption of a new, next generation document format: Office Open XML.
We've made great progress, and as previously promised we're releasing some of this new functionality in a form that you can start using right away: Beta release #1 of the Microsoft Office Open XML File Format Converter for Mac is now available for download.
This is a stand-alone Macintosh application that converts .docx documents - that is, documents saved by Word 2007 for Windows in the Office Open XML file format - into rich text format (RTF) documents so that they can be automatically opened in either Word 2004 or Word v.X for Mac OS X.
With this free converter we passionately want to get you up and reading the new documents you are receiving. We do not, however, want to see you inadvertently mess up any critical documents you are working with. For that reason, only one-way (read only) conversion is supported in this beta. When sending documents back to colleagues and contacts, we recommend saving to the default .doc format from Mac Word (listed as "Word document" in the save dialog). Similarly, we continue to recommend that you advise friends and colleagues who use Office 2007 and collaborate regularly with Mac users to save their documents as a "Word/Excel/PowerPoint 97-2003 Document" (.doc, .xls, .ppt) to ensure that the files can be robustly shared across platforms while waiting for final availability of Office 2008 for Mac.
Personally, I'm getting plenty of opportunities to use this new converter right out of the gate. Office 2007 for Windows is pretty widely deployed across the numerous PC desktops we have here internally at Microsoft. So far the converter is doing great, but then in most cases I tend to only need to read and review the documents rather than co-edit them (product plans, service agreements, draft letters, staff communications and the like). For active collaboration on critical or complex documents - e.g. where getting the formatting, tables etc. correct is essential - you'll want to continue to work with the older (.doc) format from the start.
Why a stand-alone converter application? We chose this route because it supports both Office 2004 and Office v.X for Mac users, while providing some bonus functionality such as batch conversion, and also keeping the team focused on Office 2008 by avoiding major test efforts around invasive changes to our shipping Office 2004 product. The user interface for the converter actually began life as an internal test tool (where you can imagine the batch processing comes in handy) - it was so slick it quickly became obvious that it was a great solution for the converter. You can drag and drop files onto the converter icon or application of course, but can also simply double-click .docx files to invoke it. The first thing I did is turn on this preference to immediately open a newly converted document in Word, so that I can skip the step of finding the new RTF document and dragging it to Word.
Why Rich Text Format? RTF (once called the "interchange format") is simply a highly convenient intermediate format for the beta converter to use; I'll let one of our Word experts (like Rick) expand on the technical reasons why this is the case if there's interest.
We plan to release a final integrated converter for Office 2004, which will appear as an update that allows you to simply open and save the new file formats as if they'd always been there (though, some of the newer functionality expressed in the formats will naturally only be available in Office 2008). We are on track to deliver this final integrated converter for Office 2004 six to eight weeks after Office 2008 for Mac is available. We also will release a final version of the stand-alone converter soon after.
Why wait until after we ship to release the final converters? The converters include and rely upon the same new code that lives in Office 2008 (so you're getting early access to some of the new code today - running natively as a Universal Binary, of course). As the code improves in the applications, so will the converters improve, and as a result the converters will not be final until Office 2008 is also fully complete and fully tested.
Incremental updates to the beta converter will be coming this summer, including those to roll in PowerPoint and Excel document support. If you have installed the new beta converter, these updates will be pushed out automatically through the Microsoft AutoUpdate service.
Congratulations to the product team here in MacBU on the great progress made as we approach the finish line on Microsoft's best ever release of Office for the Macintosh - Microsoft Office 2008 for Mac - and a big thanks for your hard work in building the converter.
P.S. If you are interested in learning more about the Office Open XML formats and the ways third parties are adopting and plugging into them, Brian Jones' blog is a great place to start.
There's been some pretty alarmist news stories this morning (apcstart.com; CrunchGear) about file format converters and Office for Mac. Because some of these stories seem designed more to inflame than inform, I want to reiterate our previously reported intention to provide free converters, clarify our timing for their release, and also give some direction on how best to avoid incompatibility until they are available.
Be it resolved: The Mac BU WILL issue free, downloadable file format converters that allow users to read the new Microsoft Office Open XML Format. We announced that publicly at WWDC, and nothing has changed.
Timing: We're working on our file format converters as I write. We had to wait until Office 2007 bits and the new file format itself were locked down. During this time, we spent the last year and a half prepping and planning for our own development of file format converters for Office for Mac. This included the basic supporting work of a rich and compatible XML parser, code to understand the new package structure, and beginning work on reading and writing early development versions of the file format. So now that Office for Windows has been released, we are working on completing compatibility with the released formats, while also completing other major work such as moving our codebase to the Intel platform, which we have discussed at some length on this very blog and elsewhere. We are running on target and expect to release a free public beta version of the file format converters in Spring 2007, with final converters available six to eight weeks after we launch our next version of Office for Mac (which, as previously reported, will be available 6-8 months after general availability of Win Office.) The next version of Office for Mac will natively read the Open XML Format; users of the current version of Office will have converters in order to maintain compatibility with the new Office for Windows.
There will be a delta between general availability of Win Office (January) and converters from MacBU (expected late March/early April.) We realize this will be an inconvenience for some of you (trust me, we know - 90% of Microsoft has been dogfooding Office 2007 for many months, and we in the MacBU are well used to asking for down-reved versions ourselves). For now, we recommend that Mac users advise their friends and colleagues using Office 2007 to save their documents as a "Word/Excel/PowerPoint 97-2003 Document" (.doc, .xls, .ppt) to ensure the documents can be shared across platforms.
Brad's Carl Sagan-style post on code size stirs up some familiar questions about complexity management here at MacBU. With every release of Office, we remove, rewrite and add new code. Often we can remove significant amounts of code without losing functionality -- say, remove use of a custom HTML renderer when the OS offers a built-in one instead. I recall how many of us took it as a badge of pride during the Carbon transition of Office v.X that after a year of intensive coding our net contribution in terms of new lines of code was significantly negative. Those were the days, hacking and rewriting. But of course, as the total functionality of the suite increases over time, the total volume of code used to build it tends to inevitably follow. There has been a lot of functionality added in twenty years.
Is it necessary? It's pretty easy to find people who agree that Office has more functionality than they personally need. Where the agreement tends to fall apart is when you ask what the first feature to be cut should be, at which point one person's "bloat" is another's "only feature I use every day". It's also nice to know the functionality and compatibility is there, as you find the need or the advantages of it. I use all of our apps every day, not to test but just to get work done -- Exchange-based mail and calendaring in Entourage, analyzing data and lists in Excel, IMing over corp chat -- it's an interesting job being able to use the software every day to talk about the job of making the software. My Office skills were pretty minimal when I got here, but (and some coworkers might smirk at this) they've come a long way. You may not have heard of (say) pivot tables, but once you start using them for certain kinds of analysis you can't imagine how you ever lived without them.
Of course, our goal isn't to just pile features on top of features, but to harness the increasing power in the suite with an effective and focused user experience that puts functionality in reach and in context. In some cases that can be pretty easy, but generally it's actually pretty hard, and something we have to think about with everything we do.
Is it slow? Generally, there's no linear relationship, where adding 10% code means everything is 10% slower. There's quite a lot of engineering happening down at the metal to swap in the currently executing code as the application runs. The problem is in how much work the application is trying to do -- if it's trying to do a lot, it's necessarily going to take longer to do. When we work on performance bottleneck areas (such as boot speed) that is generally what we are looking at, i.e. do we really need to be doing all this now? For this release, running native on Intel is orders of magnitude more important for speed than trying to trim raw code size, for example.
Is it sustainable? It's important to understand that while the code has been written and expanded over the past twenty plus years, it has also been tested and validated for twenty plus years. Insane amounts of testing. Stabilized or "baked" code provides a baseline for correctness and quality -- as new changes introduce unintended problems (regressions), we know we just need to hunt down which new change is the culprit and understand how it needs to be redone. The real impact is on productivity: while correct, that baked code can vary wildly in how well factored it is (well factored being the opposite of "spaghetti"), and therefore how sensitive to regression. We definitely have some pasta mixed in as part of our overall diet, and we have to develop strategies for dealing with that. Sometimes it's best to simply say "do not disturb the water", but that's not always an option (say, for example, you decide to blow out the Excel cell table.)
Shouldn't we just rewrite it all from scratch, and "do it right" so that *all* of the code is perfectly well factored according to modern sensibility? JoelOnSoftware made some great observations on that topic in this article: Things You Should Never Do, Part I. (I believe link-master Brian sent that to me originally. Pyramid was before my time here so I'll leave it to others to comment on whether Joel's observations on that project are fair and accurate or not.)
Some people keep souvenir copies of tech editorials from ten years ago predicting that Microsoft will be unable to release any further versions of Excel, because the code base has simply gotten too big and Microsoft will have to rewrite it from scratch. That was quite a few releases of Excel ago.
Joel points out that code doesn't rust, but the complexity problem is real because massive change is inevitable if you are trying to keep your software on the leading edge -- especially on the Mac. We plan to continue shipping Mac software into the foreseeable future, so it is easy for us to make major architectural decisions with the very long term in mind. Where it gets hard is balancing this against short term customer need -- what resources can we apply to deep rearchitecture or local refactoring, given that these resources will not be available to solve the most pressing problems that are actually visible to customers? While we made significant investments in future capability earlier in the current product cycle, right now that customer need is pretty extreme and we're 100% focused on getting this release out into the market.
Finding this sort of balance overall, and dealing with this level of complexity in general, is clearly our defining challenge with Office. It takes some time to get your head wrapped around it all. We might go days without seeing a particular new developer, and we'll have to send a veteran search and rescue squad into their area of the code to pull them out. Of course, it doesn't just impact developers, it's in the density of the test cases, the maintenance of the automation, the range of functionality and interactions our designers have to understand, the scope of documentation, the pace of change. Managing complexity is where we live. It's not for everyone, but fortunately I find it all pretty fun at the end of the day... gives my head something to do.
A friend of mine and I were shooting the ... breeze (freaking 'G' ratings for blogs) and he was asking me when the next version of Office was coming out. Now being the wise Microsoft spin doctor that I am, and having spent numerous hours being brainwashed by marketing, p.r. and some guys in black who look like Jessie Ventura and Alex Trebek (anyone get that reference?) I looked him square in the eye and asked, "How many lines of code are there in Mac Office?"
Not to be caught off guard, he stared right back and asked, "You're going to kill me after you tell me, right?" I smiled that Cheshire cat smile I have and said, slowly, "Maybe ...." I let the pause go on for a bit longer than normal and then laughed.
So I changed the subject to movies and after a bit he asked me, "How many lines of code are there in Mac Office?" I looked him and asked, "Do you really want to go there? " He nodded as he moved his lawn chair a little out of arm's reach.
About 30,000,000 lines of code make up the current version of Office that we are developing. That's no typo; in fact, I had to figure that out because of a research project I was working on ... if I told you what it was, I would definitely have to ... oh, yeah, 'G' ratings ... anyway back to the train of thought.
It's really mind blowing when you think about it. Each developer is responsible for, on average, about 428,000 lines of code. Some people have more areas, some have less, but if you just think of that number, that's a tremendous amount of responsibility per developer. Consider for a moment also that there are probably 10x (yes ten times) or more developers on Windows Office, although I don't know the exact count.
Just to throw another mind-numbing number out at you, there are about 40 lines of text on the page of an average paperback book. That means one developer is responsible for about a 10,700-page book. Or if you break it down smaller, if the average paperback is 300 pages, that means each developer is responsible for about 35 or more paperbacks on his desk. Imagine trying to find a single typo in all those books -- that's what most bugs are, don't ya know!
Rick might have a better guess, but from what I have seen the average life of the code (before this version), was about 12 years, meaning most of the code was written back when 68k and 386 processors ruled the world. A5 bring back any memories for people? What about segmented memory? Why is this important? Read on.
The final killer number that I think is important in answering my question is 50%. What does that number mean? It represents the amount of turnover we have had in our developer organization in the past two years. Let that sink in for a bit: during these past two years we started the move to XCode, then started the move to Intel, brought on about a bunch of new people and asked each of them to learn somewhere on the order of 400,000 lines of code. Most of which was written before some of these new hires started high school! Either that, or they started work on a brand new feature and we pushed all the responsibilities of that code onto people who never saw it before or were already working on other things.
I guess the short answer to my friend's question is that the next version is coming out as fast as we can develop it. Everyone in the MacBU, developers, testers, UA, PM, Loc, and managers are trying to make this the best version of office for both PowerPC and Intel based Macs. But as we have said before on this blog and will continue to say, we're making progress, staying on track and hoping to get this puppy wrapped up and shipped off to you as soon as possible. But for now we're all trying to get through our 35 books trying to find those blasted typos.
Oh, and for the record, I think I have about 50 or so books on my desk ... some are written in OLE ...
The last event of C4 was a visit to Chicago's Adler Planetarium, with a special behind the scenes (and beneath the stairs) tour of the computer room that runs the video conferencing room and the CyberSpace classroom. Well, "room" is charitable. "Closet" would be better. "Crawlspace", "pit" or "graduate student living arrangement" would also work.
Contrary to the skeptical whisperings of some of the Planetarium staff ("Why are you showing them closets?"), the highlight was easily the rack of more than two dozen G4 cubes wired up as the brains of the classroom workstations.
I find great irony in the fact that a machine which was originally designed more as an objet d'art than a computer turns out to be a very useful computer for a museum, and a group of programmers come to appreciate the techno-beauty of the installation, even if it is in a closet.
I'll leave you with a few classic quotes from C4, as best I can remember them. It's been great being your weekend guest-blogger. Thanks for reading.
- Olof
"It was like an unwritten rule, except that it was written." - John Gruber on the Human Interface Guidelines
"Who'd have thought I'd be up here saying how wonderful NavServices is?" - Brent Simmons "It was like making apples from applesauce." - Brian Fitzpatrick on writing cvs2svn
"Before MySpace, we had friendships. Before NBA Live, we had basketball. Before Second Life, we had life. Before Delicious Library, we had shelves." - Aaron Hillegass on the importance of solving real problems
"Subversion is not a big truck." - Brian Fitzpatrick
C4 is over and I'm back in Seattle, which means these last two posts will be Almost Live-blogging C4.
I get about 60 emails every day from a robot. Well, not a robot that moves around, but our version control system -- the server that manages our project's source code. Every time someone checks in a change to the source code, the system sends out email to everyone that includes information about what got changed, who changed it, and their comments about that change.
MacBU is somewhat schitzophrenic in that roughly half of our development team is in Redmond, and half in Silicon Valley. I'm in Redmond, so when I started at MacBU, I got to know the SIlicon Valley part of the team primarily via email, a good deal of which was from the source control system. And there are also smaller parts of our team in Ireland and Japan and China where the email communication is even more important.
Our system is set up this way so as to encourage good collaboration. For example, knowing that everyone will get email that contains the checkin comments, most people try to write decent checkin comments. This good for team communication in the present, but it is also crucial for helping our future selves, when we'll look back on our checkin comments from today and try to answer the crucial question "What were we thinking?".
But 60 emails a day is overload. I usually scan them but often don't have the time to follow closely what people have been working on. They are still helpful, of course, but the lessons are clear -- our software systems help us communicate within the team, and thereby build team cohesiveness and awareness, but there are obvious limitations.
So what got me thinking about this? Brian Fitzpatrick, one of the people behind Subversion, the latest and greatest open-source source control project, spoke at C4 on Saturday. Brian had a number of examples of how the features available in a version control system affect the community that uses it, and he talked about trying to make decisions about the design of Subversion with the community dynamics in mind.
Interestingly, its not always obvious what the 'right' choice is, and indeed, there are cases where one project might want a certain feature done one way, and another community might want a completely different implementation. For example, the very meaning of 'checking in' might be very different. At MacBU, checking in means taking responsibility that the code works and doesn't break the existing build. But in another setting (think Wikipedia), checking in could mean "here's my ideas for what this file should be -- what do the rest of you think?".
The trend of thinking about software not just as a set of features, but instead as a foundation for community building isn't a new one, but it still surprising how far reaching and subtle the influences can be. Working on the Mac Office products, we use the phrase 'personal productivity' quite a bit, and most people know really well what makes themselves productive.
We also care about 'team productivity' and 'collaboration', but those things can mean different things to different people, and they are much harder features to deliver, especially when 'personal productivity' can be at odds with 'team productivity'. It's more evidence that there's plenty of innovation still needed in our market segment, and why there's a future for Mac Office well beyond the horizon we can see today.
