…just different requirements and constraints.

The top story on programming.reddit this morning is an example of how differently people can view the same incident and how it relates to making design decisions when trying to ship a software project.

Almost a decade ago, Joel Spolsky wrote an article entitled Two Stories which contrasted his time working at Microsoft with his time working at Juno (a popular ISP from back in the day). Below is the relevant excerpt from Joel's article which talks about his time developing the macro language that was to be used by Excel.

My first assignment at my first job was working at Microsoft, where I was told to come up with a new macro language strategy for Excel. Pretty soon, I had the first draft of the "Excel Basic" spec (which later evolved into Visual Basic for Applications, but that's another story). Somehow, this mysterious group of people at Microsoft called the "Application Architecture" group got wind of my spec, which must have concerned them, because for some reason they thought that they were in charge of things like macro language strategies, and they asked to see my spec.
…
So I proceeded to ignore them as diplomatically as possible.

This seemed to piss off a guy named Greg Whitten who headed up the App Architecture group. Now, Greg was something like Microsoft employee number 6. He had been around forever; nobody could quite point to anything he had done but apparently he had lunch with Bill Gates a lot and GW-BASIC was named after him. Greg called a BIG MEETING and proceeded to complain about how the Excel team (meaning me) was screwing up the macro strategy. We pressured him to come up with some specific reasons but his arguments just weren't convincing. I thought it was nice that here I was, a new hire pipsqueak right out of college, arguing with employee number 6 and apparently winning the argument. (Can you imagine that happening at a Grey Flannel Suit company?) My programming team, headed by Ben Waldman (now a VP at Microsoft) backed me up completely, which was all that really mattered, because the programming team wrote the code and thus had the final say on how things got done.

Five years later, John Foust tracked down Greg Whitten to get his take on the same incident and then republished Greg's private response on the classic computing mailing list. The relevant excerpt from Greg Whitten's mail is below

On the Joel Spolsky subject he was a basically ignorant junior employee who left Microsoft after a short number of years. His short sighted decisions to take the VB macro language in Excel in its own directions caused 6 other major applications that were doing BASIC macro languages to diverge and not be able to share any macro programs between the applications. He made other similarly stupid decisions like creating a custom programming interface for BASIC in Excel instead of sharing a common interface as strongly recommended. The applications group spent 30 man-years integrating custom interfaces for each application with the Office 95 applications. In Office 98 they tossed it all and went back to my original suggestion which only took 1.5 man-years to develop and provided better commonality and learning between the applications.

It is instructive to compare both approaches to solving the same problem. Joel seems to be a believer in the philosophy that shipping is a feature which means you execute on your project by limiting dependencies while making sure you are building specific solutions to customers problems. Greg was big picture guy who wanted to ensure that all of the various BASIC macro languages being developed by different groups at Microsoft were compatible and could developers could easily port applications between them. They both have a point, on the one hand the designer of the Excel macro language shouldn't have to be limited by the constraints of building macros for Outlook but on the other hand anyone building common tooling or infrastructure for macros in Office would prefer that there weren't significant differences in the various macro languages in the product suite. So you end up with two smart people with contradictory goals and it is thus unsurprising that each thinks the other is ignorant.

The unfortunate thing about this entire incident is that it would have been a great learning experience for Joel if he had stayed on in Excel to see some of the consequences of his design decisions and then be in a position to consider whether he'd made the right tradeoffs in the first place. Of course, this is pretty commonplace when it comes to large software platforms where people can spend 3 – 5 years working on a single release which in combination with an average job tenure of 4 years in the U.S. (probably less in fast paced the software industry) means that many people never learn from their mistakes or improve their skills over time.

~~

As a program manager at Microsoft, I'm often in the same predicament as Joel was when he started working at Excel. Although the same challenge exists at every big software company, Microsoft is unique in its breadth of software offerings which means that almost every technology choice or design decision you make is an opportunity to pay some sort of strategy tax. The key thing I always keep in mind is that shipping is a feature and building software that delights our customers should have the highest priority. Being able to articulate how your choices reflect both of these points during every phase of the project is part of being a good program manager. Joel was able to do that, which is why he got to ship his project how he saw fit.

Now Playing: Korn - Freak On A Leash