Scene: A fly-over view of Microsoft's campus focuses in on the building that houses Mac BU. The camera "flight" enters one of the offices through a window. During the fly-over, a voice-over says:
- New 3.0 GHz Mac Pro: $3,599.00
- Two 23" Apple Cinema HD Displays: $1998.00
- Office space: $350.00/mo
- Competent developer...
You get the picture. For years, one of our program managers has been coming into my office with feature questions that invariably begin with, "Is it possible to...?" Well, of course it's
So, earlier this week, we announced that we're not going to ship a Universal version of Virtual PC and that we're going to discontinue support for Visual Basic for Applications. The latter is particularly painful for a number of our customers, and people are quite understandably livid about it.
While Erik Schwiebert has posted a sound explanation of the technical hurdles involved, there remains the more general question of finding the resources capable of doing the work required to overcome those hurdles. Many people who are not at all familiar with the exigencies of software development look at Microsoft's balance sheet, and the maxim that anything's
There are two pieces in the people puzzle. The first is head count, and, for various reasons, Mac BU has always operated with open head count. "Open head count," means having a budgeted slot to hire someone, but not having an actual employee in that budgeted slot. Due to the turn-over of people who move on to new challenges, and the difficulty of finding candidates who we believe won't write something worthy of being posted to The Daily WTF, despite the steady stream we keep interviewing, I don't see this condition changing in the near future.
The fact that we've always had open head count points out a subtle aspect of the budgeting issue. Picture yourself being Roz Ho's boss. She comes to you asking for an increased budget for more head count. You look at the existing budget, and see that there are open head count. Your question is likely to be, "Why are you asking for more head count when you haven't filled the head count you already have?" The point: the people resource issue isn't a budgeting problem.
The second part of the people issue is a bit more difficult to understand when you haven't spent a great deal of time trying to ship software in the real world, but there is a point where adding new people to a project results in diminishing returns. Fred Brooks refers to this as the Mythical Man Month. If you ask me whether Mac BU is still on the increasing side of the curve or if we've come close to the diminishing side, I'd honestly have to say that I really don't know. This is one of those cases where you don't really know you've hit the point of diminishing returns until you get there, and, even then, recognizing that that you have is exceedingly difficult. There are a number of variables that affect the time it takes to complete a software project, and it's very difficult to account for them all.
However, Schwieb's estimate of two or more years to rework VB/VBA isn't far off the mark, and it assumes that we put every resource onto that project that we can possibly put on it. That estimate also takes into account the issue of dependencies. This part of the Mythical Man Month isn't all that well discussed in the Wikipedia article linked above, but it's one of the more important problems we face. The number of people you can effectively put on a project is determined by the number of discrete tasks into which the project can be broken down and by the extent to which those discrete tasks depend on the completion of other tasks.
Consider the VBA execution engine that Schwieb mentioned. One might be tempted to take each opcode, and turn that into a discrete task to be worked on by an individual developer. Unfortunately, that kind of approach will lead to less coherence in the overall project. Are there any common elements to certain subsets of the full set of opcodes? If there are, and we have one developer per opcode, then there's a high probability we'll have a large number of subtly different implementations of these common elements. The more discrete tasks into which you break up a project, the greater the logistical difficulty of integrating each of those discrete tasks into a coherent whole.
Now, I've read a number of suggestions that people have made: take a Ruby on Rails approach, figure out a way to use PowerPC/CFM VBA running under Rosetta, and a few others I can't recall off the top of my head. There are ideas we'd explored that I haven't seen anyone suggest. I can't think of any one of them that would not have involved more work than working with the design parameters of the current VBA implementation--not the least of which is the fact that all of the applications implement their object models using the OLE Automation, dual-dispatch/type library approach. One has to be very careful with such ideas, because there are a number of hidden gotcha's that are very difficult to accurately assess.
So, could we have done something about VB/VBA? Certainly, if we'd had enough time. Do we make those users who really don't care about VB/VBA wait several years before we ship a Universal Binary version of Mac Office? At some point, the tail starts to wag the dog.
But that does not mean we are unaware of the pain this will cause to a significant number of users. If you think we are not aware of that pain, consider this. David Weiss can give you a better number on this, but our testing methodology has always made extensive use of scripts for automated tests. Not just a couple of scripts, but thousands of scripts
Currently playing in iTunes: Feel So Bad by The Derek Trucks Band