Wolfgang Sommergut

Gemeinhin stellt man sich Microsoft als ein gut organisiertes Unternehmen vor, bei dem die verschiedenen Abteilungen und Sparten wie die Zahnräder eines geölten Getriebes ineinander greifen. Die Dominanz in einem Marktsegment spielt die Firma in einem anderen gekonnt aus und drängt Konkurrenten an den Rand. Auch wenn Microsoft ein sehr gut geführtes Unternehmen sein mag, seine schiere Größe und die Unzahl der Produkte zeitigen bisweilen Effekte, die man typischerweise der IBM zuordnen würde.

Das SDA Asia Magazine veröffentlicht (leider nur in Print) ein Interview mit dem Chefentwickler der Active Server Pages (ASP) Scott Guthrie. Der plaudert u.a. über die Anfänge von ASP.NET. Zu einer Zeit, als .NET unter dem Codenamen Next Generation Windows Services als das nächste große Ding aus Redmond propagiert wurde, wusste das ASP-Team gar nicht, dass ein Paradigmenwechsel bevorstand. Dass ASP.NET auf die .NET-Runtime aufsetzt, verdankt sich mehr oder weniger einem Zufall:

We then bumped into the common language runtime team, so we just got the appointment to construct a few things. Anyway, we got excited about what they were doing; they got excited about we were doing and we actually decided to throw away the two weeks of code we have already written and start again using the CLR.

In die gleiche Kerbe haut Mark Lucovsky, ein altgedienter Software-Ingenieur und Key Architect für Windows, der kürzlich zu Google wechselte. Dort traf er auf einen anderen Ex-Microsoftie, der in der gleichen Gruppe gearbeitet hatte wie er und den er aber erst bei Google kennenlernte. Mark zielt in seinem Blog-Posting nicht nur auf die Unübersichtlichkeit bei Microsoft ab, sondern beleuchtet auch einen anderen wichtigen Aspekt des Software-Geschäfts von Bill Gates: seine Schwerfälligkeit. Er kratzt an dem Ruf von Microsoft, wonach es die Firma verstehe, Software in den Markt zu bringen:

The software sits in a source code control system for a minimum of two years (significantly longer for some of the early Longhorn code). At some point, the product that the fix is a part of will „ship“ meaning that CD’s will be pressed and delivered to customers and OEM’s. In best case scenarios, the software will reach end users a few months after the Release To Manufacturing (RTM) date.

Microsoft hängt nach seinem Verständnis einem veralteten Modell an, das größere Updates von wichtigen Produkten nur mehr alle drei bis vier Jahre zulässt. Der zeitgemäße Ansatz sieht für ihn anders aus:

When an Amazon engineer fixes a minor defect, makes something faster or better, makes an API more functional and complete, how do they „ship“ that software to me? What is the lag time between the engineer completing the work, and the software reaching its intended customers? A good friend of mine investigated a performance problem one morning, he saw an obvious defect and fixed it. His code was trivial, it was tested during the day, and rolled out that evening. By the next morning millions of users had benefited from his work. Not a single customer had to download a bag of bits, answer any silly questions, prove that they are not software thieves, reboot their computers, etc. The software was shipped to them, and they didn’t have to lift a finger. Now that’s what I call shipping software.

Das Zauberwort für einen solchen Dienst am Kunden heißt „Software als Service“. Marks neuer Arbeitgeber hat sich ebenfalls dieser Idee verschrieben.