Architecture Journal: Interview mit Scott Guthrie über Architektur und Karriere
Scott Guthrie ist ein General Manager in der Developer Division von Microsoft. Er führt die Entwicklungsteams, die die CLR (Common Language Runtime), ASP.NET, WPF (Windows Presentation Foundation), „WPF/E“, Windows Forms, IIS 7.0 (Internetinformationsdienste), Commerce Server, .NET Compact Framework und die Visual Studio Web and Client Development Tools entwickeln. Im Rahmen der Profilreihe im Architecture Journal hat sich Ron Jacobs (RJ) mit Scott (SG) unterhalten und ihn über seine beruflichen Laufbahn und zu seinen Gedanken zur Architektur befragt.
RJ: Heute sprechen wir über dich und deine Karriere, um den Leuten einen Eindruck zu vermitteln, die das für einen coolen Job halten. Welche Rolle hast du derzeit bei Microsoft?
SG: Ich bin Leiter unserer .NET-Entwicklerplattform-Gruppe. Diese Gruppe umfasst die CLR (Common Language Runtime), das .NET Compact Framework, IIS (Internetinformationsdienste), ASP.NET, Atlas, Commerce Server, Windows Presentation Foundation, Windows Forms und unsere Entwicklungstools für Webanwendungen in Visual Studio.
RJ: Wow, das ist eine Menge!
SG: Es macht viel Spaß. Es umfasst unsere Kernanwendungsmodelle, die Laufzeit, die Tools und die ganzen Module, auf denen diese aufbauen. Das ist viel cooles Zeug und eine Menge Arbeit.
RJ: Die meisten Leute werden sich an dich aufgrund Deiner Arbeit an ASP.NET erinnern. Sprechen wir doch kurz über deine frühen Tage bei Microsoft. Wie fing das alles an?
SG: Ich fing 1996-97 im IIS-Team an und arbeitete an unseren Kernwebservertechnologien. Ich war auch an der Entwicklung einer Version von IIS beteiligt. Nachdem IIS 4 veröffentlicht wurde, begannen wir, uns mit Elementen für das Webprogrammiermodell der nächsten Generation zu befassen. Zu der Zeit haben wir gedacht, „Vielleicht war's das. Gibt es im Bereich der Features noch etwas zu tun?“
Wir haben mit vielen Kunden geredet und uns die Anwendungen, die sie entwickelten, genau angesehen. Wir haben sehr schnell gemerkt, dass es noch eine ganze Menge zu tun gab. Die Leute hatten Schwierigkeiten mit der Trennung von Code und Inhalt und mit dem Schreiben von sauberem Code. Wir machten Witze darüber, dass der Code nach dem Motto „einmal schreiben, niemals lesen“ erstellt wurde. Was Tools und Laufzeitverwaltung anging, gab es viele Möglichkeiten, die Arbeitsweise unserer vorhandenen Infrastruktur zu verbessern. Um dies zu erreichen, bildeten wir ein kleines Team, das über zukünftige Architekturen mit IIS nachdachte. Das ist das Team, das den HTTP.SYS-Kerneltreiber erfunden hat, den wir mit Windows Server 2003 eingeführt haben. Mit einem Kollegen begann ich dann, an Teilen des Webprogrammiermodells zu arbeiten und entwarf den Prototyp für das, was später ASP.NET wurde.
RJ: Anscheinend wolltest du das weiterentwickeln und dabei etwas nutzen, was damals ein Riesengeheimnis war. Ich erinnere mich an diese Tage vor .NET, du nanntest das damals ASP+.
SG: Wir haben es ursprünglich XSP genannt, und die Leute fragten andauernd, was das X bedeuten sollte. Zu der Zeit bedeutete es einfach gar nichts. XML begann damit und XSLT ebenfalls. Alles, was cool war, schien mit einem X zu beginnen, daher nannten wir es erst einmal so. In den ersten sechs Monaten haben wir .NET nicht verwendet. Die CLR existierte zu der Zeit noch gar nicht, mit der Entwicklung wurde damals gerade begonnen. Daher erstellten wir die meisten unserer Prototypen in C++, Javascript- und ActiveScript-Skriptmodulen. Wir wollten eine objektorientierte Umgebung, und wir mochten die Charakteristika, die ein verwaltetes Programmiermodell in Hinsicht auf Garbage Collection, guter Kapselung und Objektorientierungsverfahren bot. Wir schrieben den ersten Produktionscode in C++, denn zu der Zeit hatten wir keine wirklich gute Laufzeitplattform, auf der wir aufbauen konnten. Als wir gerade zwei Wochen dabei waren, trafen wir das CLR-Team. Zu der Zeit hatte das Team keine Partner innerhalb des Unternehmens, die auf ihrer Arbeit aufbauten. Der einzige Compiler, den sie hatten, war dieses Ding, das sich „single managed C“ nannte. Wir sagten schließlich: „Vielleicht sollten wir darauf aufbauen“. Es war ein großes Risiko, und zu der Zeit bestand unser Team nur aus drei oder vier Leuten. Wir durften dieses Risiko damals eingehen, weil es niemanden wirklich gekümmert hätte, wenn wir gescheitert wären. Zum Glück klappte es und es zahlte sich wirklich aus. Der Rest ist Geschichte, um das mal so zu sagen.
RJ: Ich erinnere mich an die Zeit. Am Anfang der CLR war kaum jemand bereit, das Risiko einzugehen. Viele Teams haben gesagt, nicht mit uns, aber ihr habt das durchgezogen, und es hat sich wirklich gelohnt.
SG: Ja, die Leute waren über die Idee der Garbage Collection auf dem Server entsetzt, und heute nehmen wir das als selbstverständlich hin. Sie sagten damals: „Es gibt keine Möglichkeit, eine Anwendung zu erstellen, bei der eine Garbage Collection im Hintergrund ausgeführt wird. Euer Server wird nie skalieren.“ Es gab eine Menge Unkenrufe. Was das Projekt anging, zahlte sich vor allem eine unserer Ideen aus. Wir sagten: „Wir setzen auf verwalteten Code, und es wird kein Wrapper um systemeigenes Zeug herum sein. Wir werden es tief in die Plattform integrieren. Wir wollten 95 % unseres Codes als verwalteten Code schreiben.“
Dafür gab es zwei gute Gründe. Zum einen wollten wir den Vorteil der Erweiterbarkeit, den das bot, voll ausnutzen und objektorientierte Erweiterbarkeit wirklich tief in die Plattform integrieren. Zum anderen wussten wir, dass Kundenanwendungen aus verwaltetem Code bestehen würden, und dass unser Anteil an Code in einer Aufrufliste – verglichen mit dem Anteil des Kunden – verhältnismäßig klein sein würde. Wenn nicht einmal wir daran glaubten, dass wir in verwaltetem Code schreiben konnten, brauchten wir von den Kundenanwendungen dahingehend gar nichts zu erwarten. Wir mussten einfach in diese Richtung gehen. Von Anfang an passten wir durch das Erstellen zunehmend komplizierter Beispiele das CLR-Kernmodul an unsere Bedürfnisse an. Das führte für die Kunden zu riesigen Ersparnissen, als wir damit begannen, kompliziertere Kundenanwendungen zu integrieren. Es war das Risiko wert.
RJ: Es ist interessant, dass du das als eine Möglichkeit siehst, Verbesserungsmöglichkeiten auf die Engine auszurichten. Du sagtest: „Wir machen das nicht nur, wir verbessern die Engine auf diese Weise sogar“.
SG: Ich glaube, das war ein großes Risiko, aber es war ein Ansatz, der sich auszahlte. Die Tatsache, dass wir ein kleines Team waren und mit einer neuen Codebasis begannen, half ungeheuer. Wenn wir ein größeres Team gewesen wären oder auf einer bereits vorhandenen Codebasis hätten aufbauen müssen, wäre es schwieriger gewesen, weil COM-Interoperabilität damals nicht existierte. Aber die Tatsache, dass wir ganz neu und klein anfingen, hat wirklich geholfen, die Kernverbesserungen tief in die Engine zu integrieren. Als wir größer wurden und unserer Funktionalitätsangebot wuchs, machte es sich bezahlt.
RJ: Ich finde es klasse, dass deine Manager dir diese Entscheidung überließen.
SG: Es war definitiv ein Glücksspiel, aber ein kalkuliertes. Es konnte ein großer Vorteil werden, wenn wir es schaffen, aber wir waren ja nur drei oder vier Leute, und wenn es schief gegangen wäre, hätten wir im nächsten Jahr einfach etwas anderes gemacht. Microsoft ist oft diese großen Risiken eingegangen, und für gewöhnlich zahlen sie sich aus. Manchmal tun sie das nicht, und das kann spektakulär in die Hose gehen, aber als Unternehmen versuchen wir sicherzustellen, dass wir in einigen Schlüsselbereichen auch größere Risiken eingehen.
RJ: Musstet ihr jemanden überreden, das Risiko eingehen zu dürfen, oder war es ganz leicht?
SG: Wir mussten sicherlich einige Leute überreden. In der Anfangsphase des Projekts hatten wir Prototypen mit funktionierendem Code, den wir den Leuten zeigen konnten. Oft, wenn man an einem Projekt arbeitet, das neu oder etwas vorher noch nie dagewesenes ist, erstellt man ein paar Powerpoint-Folien, die sich ganz gut anhören, aber es ist besonders nützlich, wirklich funktionierenden Code vorführen zu können. Der Prototyp beweist nicht nur, dass es funktionieren kann, sondern man lernt dadurch auch eine Menge.
Ich versuche mit meinem Team immer, so früh wie möglich Prototypen und Beispielanwendungen zu erstellen, besonders Demoanwendungen, die wir den Kunden vorführen, damit sie sehen, wie sie eine Anwendung erstellen können. Wir versuchen, das so früh wie möglich zu machen, weil wir dadurch lernen, was funktioniert und was nicht, und entsprechend reagieren können. Ungefähr anderthalb Monate nach Beginn des ASP-Projekts habe ich einen Prototyp geschrieben, den wir Leuten vorführen konnten. Auf der einen Seite hatten wir dieses aus Komponenten bestehende, durch Steuerelemente angetriebene Modell. Damals haben wir sie übrigens nicht Steuerelemente genannt, sie waren deklarative Tags oder Komponenten. Und auf der anderen Seite hatten wir die ereignisgesteuerte Art, für das Internet zu programmieren. Wir konnten Anwendungen erstellen und entdeckten schnell, dass einige der Dinge, die wir uns ausgedacht hatten, wirklich unmöglich zu programmieren waren. Gleichzeitig entdeckten wir, dass es cool wäre, dieses oder jenes Feature zu haben, und wir bauten sowas während der Entwicklung immer wieder mit ein. Das hat ungeheuer geholfen, als wir versuchten, Leute zu überzeugen, dass wir nicht vollständig verrückt waren. Wir konnten Code vorführen, und sie konnten es verstehen. Es war trotzdem ein Risiko.
RJ: Das hört sich fast an wie das testgesteuerte Entwicklungsprinzip. Kurze Iterationen durchführen, um zu etwas zu gelangen, das funktioniert. “We eat our own dogfood“ und schreiben gegen unsere eigenen APIs, um zu verstehen, wie sich deren Benutzung anfühlt.
SG: Es ist sicher ein ähnliches Prinzip. Ich unterscheide zwischen testgesteuerter Entwicklung als Methode für die frühe Förderung von Qualität und als Methode für die Bereitstellung einer Basis, anhand derer ich meine Codebasis umschreiben und anpassen kann, ohne mir Sorgen um Rückschritte machen zu müssen. Wir halten uns sicher intern an diese Philosophie, wenn wir Produktionscode entwickeln. Ich bin der Meinung, dass sich eine Prototypphase sogar lohnt, bevor man zum Produktionscode übergeht. Das ist eines der erfolgreichen Dinge, die wir bei ASP.NET taten. Wir sagten: Lasst uns in den nächsten paar Monaten jede Zeile Code, die wir schreiben werden, wegwerfen. Einigen wir uns alle darauf. Wir werden nicht sagen: „Ach, wir nehmen das und passen es an, das können wir schon hinbiegen.“ Nein. Wir werfen es weg. Wir werden dieses Unterverzeichnis an einem Punkt komplett löschen, und so können wir viel abenteuerlicher neue Dinge ausprobieren. Wir müssen uns nicht darum kümmern, dass alles einwandfrei funktioniert, um in der finalen Version enthalten zu sein.
Wir machten das tatsächlich ein paar Monate, und als wir fertig waren, löschten wir es und fingen noch mal von vorn an. Dann schrieben wir den vollen Produktionscode und stellten sicher, dass die Qualität stimmte. Ich denke, dass viele Teams von diesem Ansatz profitieren könnten. Am härtesten ist es natürlich, sicherzustellen, dass der Prototypcode gelöscht wird. Zu oft werden Projekte nach dem Motto „Das ist gut genug.“ entwickelt. Es ist sehr schwierig, mit einem Prototyp zu beginnen und ihn stabil zu machen. Ich glaube fest an die Methode, mit einer Prototypphase zu beginnen und sie dann zu löschen.
RJ: Es zeigt, dass wir das Lernen mehr schätzen als die Dateien und Bestandteile aus der Prototypphase.
SG: Immer wenn du bei der Arbeit an einem Projekt irgendetwas neu schreibst, sei es komplett oder teilweise, wird der Code besser. Der Grund ist zum Teil, dass du die Probleme und Stolperfallen des letzten Ansatzes verstehst und dir etwas Besseres einfallen lassen kannst. Das Problem ist, dass du das nicht einfach immer wieder machen kannst. Aber wenn du zu Beginn eines Projekts oder eines ganz neuen Bereichs, wo nicht klar ist, wie du von Punkt A zum Endprodukt kommst, eine Phase hast, in der du nur Prototypen erstellst und experimentierst, das ist unglaublich wertvoll.
RJ: Einige Leute nennen dass die „architektonische Spitze“. Hier ist ein neuer Bereich, und wir erforschen ihn erst mal. Aber zu einem ganz anderen Thema. Was hast du eigentlich gemacht, bevor du zu Microsoft kamst?
SG: Ich kam direkt nach dem Studium zu Microsoft. Während meines Studiums machte ich bei Microsoft ein Praktikum. Während der Schule und des Studiums war ich an der Neugründung einiger Firmen beteiligt, arbeitete etwas in der Entwicklung und hatte meinen Spaß, aber dann ging ich direkt nach dem Studium zu Microsoft.
RJ: Wir haben mit vielen Leuten gesprochen, die Architektur interessant finden. Es scheint sehr wenige Leute zu geben, die reine Architekten sind und nur Sachen entwerfen, aber nie Code schreiben. Die meisten Leute machen beides: Sie verbringen einige Zeit mit der Entwicklung und einige Zeit mit der Architektur. Welchen Rat würdest du jemandem geben, der in der Entwicklung gearbeitet hat, aber gerne mehr mit der Architektur zu tun haben würde?
SG: Das Schreiben von Code ist eine wertvolle Fähigkeit für einen Architekten. Nicht unbedingt für die Erstellung von Produktionscode, aber zum Ausprobieren neuer Technologien und neuer Ansätze, und um herauszufinden, wie das System funktioniert. Ich schreibe heutzutage nicht mehr viel Produktionscode, aber ich verbringe jeden Tag eine Stunde oder zwei mit dem Schreiben von Code. Das kann Code für Beispiele, Prototypen oder aus Spaß für persönliche Projekte sein. Was es auch ist, ich probiere Sachen aus und denke mir Möglichkeiten aus, Dinge zu strukturieren. Praktische Erfahrung ist sehr wertvoll für einen Codearchitekten.
Darüber hinaus würde ich empfehlen, sich die Theorie von Systemkernen und die Konstruktion stabiler Systeme anzusehen. Berücksichtige einige der Prinzipien, die du überdenken möchtest, und wende sie bei der Arbeit an. Das bedeutet nicht, darüber nachzudenken, wie die Codezeilen aussehen, sondern über Einfachheit oder Stabilität oder Fehlertoleranz nachzudenken. Diese Punkte sind für erfolgreiche Systeme extrem wichtig, egal, ob es sich um eine Clientanwendung, Serveranwendung oder um ein Spiel handelt. Ein Architekt, der über diese Prinzipien genau nachdenkt und dazu gute Codiererfahrung hat, kann eine große Hilfe für ein Team sein.
Bei den Prinzipien geht es nicht darum, mit einem Assistenten zu spielen oder coole neue Sachen auszuprobieren, sondern zu studieren, wie der Prozessadressraum in einer Windows- oder UNIX-Anwendung funktioniert. Wie funktioniert das Threading und wie verinnerlicht man, wie das auf einem Multiprozessor- oder Multikernsystem aussieht? Es geht darum, diese Art Wissen aufzunehmen, über die Auswirkungen nachzudenken, sich die Zeit zu nehmen, über Trends nachzudenken und darüber, in welche Richtung sich die Technologie von der Hardware- und Softwareperspektive aus entwickelt und wie man diese Trends ausnutzen kann oder sich anpassen muss. Das empfehle ich.
RJ: Bei Microsoft haben wir Entwickler, Programm-Manager und Architekten. Die Leute fragen sich oft, was für eine Rolle ein Architekt spielt. Was ist deine Erwartung an den Architekten eines Teams?
SG: Es gibt einige Voraussetzungen, von denen wir hoffen oder erwarten, dass ein Architekt sie in ein Team einbringt. Eine Voraussetzung ist Erfahrung in Architektur und Entwicklung sowie Kenntnisse der Softwareprinzipien, von denen ich sprach. Bei dieser Art Hintergrund hoffen wir, dass ein Osmoseprozess stattfindet, d. h. dass etwas davon auf andere Teammitglieder abfärbt. Unterhaltungen auf dem Gang oder informelles Bürogeplauder können einem Team enorme Führung geben, besonders wenn man mit jungen und mit erfahrenen Entwicklern arbeitet.
Wir erwarten von Architekten, dass sie von einer technischen Perspektive aus den Weg ebnen für das, was ein Produkt machen soll. Oft führen Architekten schwierigere Arbeit an Prototypen durch und untersuchen, in welche Richtung das Produkt entwickelt werden sollte. Wir erwarten von ihnen Rat zur Richtung der Entwicklung. Was die Implementierung angeht, haben sie zudem die Aufgabe, sich sowohl das Produkt der nächsten Generation als auch das aktuelle Produkt anzusehen und Bereiche zu identifizieren, die zu optimieren sind. Zum Beispiel: Welche Bereiche sollten wir etwas anders gewichten? Welche Methoden können wir innerhalb der Codebasis implementieren, um sie zu verbessern?
RJ: Welche anderen Eigenschaften, außer umfassenden, guten technischen Fähigkeiten, machen einen erfolgreichen Architekten aus?
SG: Bei Microsoft ist die wichtigste Voraussetzung für Leute mit guten technischen Fähigkeiten, die die Architekturkarriere verfolgen möchten, dass sie im Stande sind, innerhalb von Teams und teamübergreifend zu arbeiten.
Einige dieser kommunikativen Fähigkeiten sind schwerer zu erlernen. Ein Architekt muss zwar ein praktischer Mensch sein, aber auf eine Art, durch die sich Entwickler oder andere Teams nicht bedroht fühlen. Sie sollen auch das scharfe Abgrenzen von Aufgabenbereichen vermeiden. Architekten müssen teamübergreifend flexibel arbeiten können. Sie müssen dabei vermeiden, dass Leute das Gefühl haben, der Architekt kümmert sich nur kurz um das momentan interessanteste Problem und verschwindet wieder, wenn die Dinge schwierig werden. Die Teammitglieder müssen glauben, dass der Architekt sich für das Team einsetzt und Teil einer langfristigen Beziehung ist, die bei Problemen hilft. Die sind Fähigkeiten, die ein Architekt entwickeln muss. Die erfahrenen alten Hasen unter den Architekten, die die größte Wirkung haben, können umfassende technische Fähigkeiten und Entwurfsfähigkeiten mit zwischenmenschlichen und auf die Zusammenarbeit bezogenen Fähigkeiten verbinden.
RJ: Viele Leute sagen, dass die Innovationsrate zunimmt und ständig neue Sachen herauskommen. Du hast erwähnt, wie wichtig es ist, auf dem Laufenden zu bleiben, aber schließlich haben wir alle nur begrenzt Zeit. Wie bleibst du selber auf dem Laufenden?
SG: Das ist nicht leicht, besonders im Entwicklungsbereich. Was die derzeitige Geschwindigkeit der Innovationen und des Informationsflusses angeht, kann ich mich nicht erinnern, dass sie jemals so hoch war. Ich denke zurück an die Zeit der Internetschlachten der 90er, als Internet Explorer mit Netscape konkurrierte. Damals hatte ich das Gefühl, als würden wir ständig irgendetwas ausliefern. Es war so viel los.
Von der Entwicklungsperspektive her denke ich, dass wir uns in einer Phase befinden, in der die Geschwindigkeit sogar noch schneller ist als damals. Es ist sicher sehr schwer, auf dem Laufenden zu bleiben. Man muss sich die Zeit nehmen, es zu tun. Man muss sich ganz gezielt die Zeit nehmen, das Geschehen im Auge zu behalten. Ich finde, dass Blogs dafür großartig sind. Ich bin bei Bloglines registriert. Das ist ein toller, kostenloser Service. Ich habe wahrscheinlich 300 oder 400 Blogs abonniert, und ich versuche, 20 bis 30 Minuten pro Tag morgens und abends zu lesen, was veröffentlicht wird. Dadurch erfährt man von den heißen Themen und den interessanten Ideen.
Zum auf dem Laufenden bleiben gehört auch, dass ich mich eine Stunde pro Tag auf das Erstellen von Prototypen konzentriere, indem ich Sachen ausprobiere, entweder mit meinem eigenen Produkt oder anderen Technologien. Dadurch gewinne ich eine genaue Vorstellung davon, was es auf dem Markt gibt und wie ich es verwenden kann. Der andere wichtige Punkt, wenn du dir irgendeine neue Technologie, API, Methode oder einen Programmieransatz ansiehst, ist, dass du dir nicht nur das interessante Objekt genau ansiehst, sondern versuchst, seine nützlichen Prinzipien zu verstehen, damit du sie auch anderswo anwenden kannst. Nehmen wir z. B. ein Buch über das Rfactoring von Java-Code. Es führt einige bestimmte Java-Refactorings auf, aber was sind die breiteren Umgestaltungskonzepte, die du verinnerlichen und auf VB oder C# anwenden kannst? Prima, wenn du dir ein AJAX JavaScript-Framework ansiehst, das sehr gut für eine bestimmte Aufgabe geeignet ist. Jetzt lehne dich zurück und versuche zu erkennen, welche seiner Aspekte auf ein anderes JavaScript-Framework angewendet werden können. Ein Architekt sollte die Fähigkeit haben, etwas anzusehen und davon interessante Aspekte, und nicht nur einzelne technologische Elemente, abzuleiten.
RJ: Wenn du auf Ihre Zeit hier bei Microsoft zurückblickst, gibt es etwas, das du bedauerst?
SG: Wenn man zurückblickt, gibt es immer Dinge, die man anders machen würde. Das kann eine technische Sache sein, z. B. die Implementierung eines Features, und man denkt: „Alle missbrauchen dieses Feature“. Oder Dinge werden auf eine Art gemacht, die man so nicht geplant hatte. Sicher, wenn man eine so umfassende Entwicklungsplattform wie .NET erstellt hat, gibt es Dutzende Dinge, die man im Nachhinein etwas anders machen würde. Auch bei der Art, wie man an Dinge herangeht oder mit verschiedenen Teams arbeitet, wünscht man sich z. B. manchmal, man wäre eine bestimmte Unterhaltung etwas anders angegangen. Ich könnte also jede Menge einzelne Beispiele anführen.
Insgesamt bin ich damit zufrieden, wie sich .NET entwickelt hat, deshalb sind wir damit ziemlich erfolgreich gewesen. Aber es gibt viele Dinge, von denen ich wünschte, wir hätten sie etwas anders gemacht. Zum Beispiel wünschte ich, wir hätten eine bestimmte Klasse nicht versiegelt oder die Versiegelung einer anderen Klasse nicht aufgehoben.
Es gibt eine wesentliche Sache, die ich heute anders machen würde. Ich wünschte, wir hätten am Anfang länger über den Clientinstallationsvorgang zum Erstellen von .NET Clientanwendungen nachgedacht. Ich glaube, unser Ansatz mit einer einzigen weitervertreibbaren, herunterzuladenden Datei ist nicht schlecht, aber ich wünschte, wir hätten frühzeitig die Gelegenheit genutzt, eine Installation mit geringeren Auswirkungen zu entwickeln und die Bereitstellung von Clientanwendungen zu vereinfachen. Damit verbringen wir momentan viel Zeit, und in Zukunft wird es viel besser werden, aber ich wünschte, wir hätten das vor sechs Jahren gemacht und Zeit darauf verwendet, einige dieser Szenarios ein bisschen früher zu durchdenken.
RJ: In deinem Büro hast du viele Sprecher-Namensschilder von Entwicklerveranstaltungen, die du über die Jahre gesammelt hast. Du hattest die Möglichkeit, viel zu reisen und viele Leute zu treffen. Was waren für dich die Höhepunkte? Ist dir jemand ganz besonders im Gedächtnis geblieben?
SG: Eine Sache, die bei der Arbeit an einer Entwicklerplattform großen Spaß macht, ist es, die vielen unterschiedlichen Anwendungen zu sehen, die Leute auf unserer Plattform erstellt haben. Ob das MySpace ist, das mit eineinhalb Milliarden Seitenaufrufen pro Tag die größte soziale Netzwerkplattform der Welt ist, die .NET verwendet, oder die Londoner Börse oder der Nationale Gesundheitsdienst von Großbritannien oder eine Menge Unternehmen an der Wall Street, Costco, Dell.com oder Match.com – es gibt so viele coole Kundenanwendungen, die auf der Technologie von Microsoft beruhen. Viele von ihnen sind im Internet, andere verwenden eine andere Technologie. Auf dem Gelände von Walt Disney World werden die Einlasszähler für die „Schnelleintritts-Tickets“ auf dem .NET Compact Framework und der CLR ausgeführt. Die Geräte, die die Angestellten des US-Volkszählungsbüros oder der US-Post benutzen, werden ebenfalls auf .NET Framework ausgeführt.
Das ist für mich der Höhepunkt: zu sehen, wie .NET überall auf der Welt verwendet wird. Manchmal auf seltsame, verrückte Weise, manchmal für erfolgskritische Anwendungen, aber immer auf einmalige Art, auf die ich, offen gesagt, wahrscheinlich nicht gekommen wäre. Ich glaube, dass das Kennzeichen eines guten Frameworks nicht die Anwendungen sind, die Leute damit erwartungsgemäß erstellen, sondern die Tatsache, dass Kunden und Entwickler mit dem Framework weit mehr machen konnten, als man sich vorgestellt hatte. Das ist für mich der Höhepunkt von .NET.
Scott Guthries berufliche Laufbahn bei Microsoft
Scott Guthrie kam 1997 zu Microsoft und arbeitete anfangs an IIS4 und dem Windows NT Option Pack. Bald nach der Veröffentlichung übernahm Scott den Entwurf und die Prototyperstellung eines neuen Serverprogrammiermodells, das ursprünglich den Codenamen „XSP“ hatte. Zusammen mit Mark Anders bildete er dann 1998 ein neues Team und entwickelte das, was letzten Endes ASP.NET genannt wurde.
Anfang 2002 wurde Scott zum Production Unit Manager (PUM) des ASP.NET-Teams ernannt. ASP.NET V1.1 wurde schließlich als Teil von Windows Server 2003 ausgeliefert. Während dieser Zeit leitete er auch die Anfangsphase des populären Web Matrix-Entwicklungstools, einem freien ASP.NET-Entwicklungstool, das neue Ideen für Tools zur Webentwicklung inspirierte und auf Hobbyprogrammierer abzielte. Gegen Ende 2002 wurde er auch PUM für die Webtoolfeatures von Visual Studio und war verantwortlich für die Entwicklung des neuen eigenständigen Produkts Visual Web Developer, das als Teil der Visual Studio 2005-Familie ausgeliefert wird, sowie für alle Webentwicklungsfeatures in Visual Studio. Visual Web Developer und ASP.NET 2.0 wurden zuerst als Betaversion im Sommer 2004 veröffentlicht und im ersten Halbjahr 2007 ausgeliefert.
Gegen Ende 2003 wurde Scotts Team mit dem IIS-Team verschmolzen, und er wurde PUM eines vereinigten Teams für Internetplattformen und Tools, das die Ressourcen von IIS, ASP.NET und Visual Studio kombiniert.
Scott ist derzeit General Manager von Microsofts Developer Division und führt die Entwicklungsteams, die die CLR, ASP.NET, WPF, „WPF/E“, Windows Forms, IIS 7.0, Commerce Server, .NET Compact Framework und die Visual Studio Web and Client Development-Tools entwickeln.
Scott schloss 1997 sein Informatikstudium an der Duke University ab.
