Ein neuer Blick auf die uralte Frage: Sollte die Anwendung von Grund auf neu geschrieben werden oder ist es „der schlimmste strategische Fehler, den ein Softwareentwickler machen kann“? Es stellt sich heraus, dass es bei der Arbeit mit einer ausgereiften Codebasis mehr als zwei Antwortoptionen gibt.

"Der Quellcode scheint verrostet zu sein !" - Joel Spolsky

Vor fast zwei Jahrzehnten inszenierte Joel Spolsky Netscape, weil er die Codebasis des Browsers in seinem wegweisenden Aufsatz „What You Can Never Do“ neu geschrieben hatte . Er kam zu dem Schluss, dass funktionierende Software niemals von Grund auf neu geschrieben werden sollte . Er hatte zwei Hauptargumente:

• Müll-scheinbare Teile der Codebasis enthalten oft schwer verdientes Wissen über Grenzsituationen und seltsame Fehler.
  
• Die vollständige Änderung ist ein langfristiges Unternehmen, das von der Verbesserung des vorhandenen Produkts ablenkt und den Wettbewerbern Trumpfkarten gibt.

Für viele sind Joels Erkenntnisse zu einem Dogma geworden. Einmal hatten sie einen großen Einfluss auf mich. In den folgenden Jahren wurde mir jedoch klar, dass es unter bestimmten Umständen immer noch sinnvoll ist, das Produkt vollständig zu überarbeiten. Zum Beispiel:

• Manchmal ist eine veraltete Codebasis wirklich nicht wiederherstellbar, sodass selbst ein einfaches Upgrade kaskadierende Änderungen in anderen Teilen des Codes erfordert.
  
• Ursprüngliche Technologielösungen können die notwendigen Verbesserungen beeinträchtigen.
  
• Oder die ursprüngliche Technologie ist möglicherweise veraltet, was es schwierig (oder zu teuer) macht, qualifizierte Entwickler einzustellen.

Natürlich hängt viel von den Umständen ab. Ja, manchmal ist es sinnvoll, veralteten Code schrittweise umzugestalten. Und ja, manchmal ist es sinnvoll, alles wegzuwerfen und von vorne zu beginnen.

Dies ist jedoch nicht die einzige Wahl . Werfen wir einen Blick auf sechs Geschichten und sehen, welche Lektionen gelernt werden können.

---

1. Netscape

Der Browser-Code wurde dreimal von Grund auf neu geschrieben

Der katastrophale Übergang von Netscape von 5.0 auf 6.0 war Anlass für den oben genannten Artikel von Joel Spolsky und viele waren davon überzeugt, dass dies niemals geschehen sollte.

Netscape Navigator wurde 1994 in den Anfangsjahren des kommerziellen Internets veröffentlicht. Zwei Jahre später eröffnete das Unternehmen die Dotcom-Ära mit einem Börsengang von 3 Milliarden US-Dollar.

Der erste große Konkurrent von Netscape war Microsoft Internet Explorer, der 1996 veröffentlicht wurde.

Anfang 1998 war Netscape immer noch der führende Browser, allerdings mit großen Schwierigkeiten. Netscape war ein kommerzielles Programm, das für 49 US-Dollar verkauft wurde. Microsoft verteilte den IE kostenlos und lieferte ihn als Standardbrowser unter Windows.



Mit der Veröffentlichung von Netscape 4.0 gab das Unternehmen bekannt, dass die nächste Version kostenlos sein wird und von der Open Source-Community entwickelt wird, die von Mozilla erstellt und finanziert wird. Für seine Zeit war dies im Wesentlichen ein beispielloser Schritt, und Netscape gewann viele Unterstützer für eine solch mutige Entscheidung. In Wirklichkeit kam diese „Gemeinschaft“ jedoch nicht zustande. Jamie Zawinski, einer der ersten Browser-Entwickler, erklärt :

Die Wahrheit ist, dass an dem Mozilla-Projekt ungefähr hundert Vollzeit-Netscape-Entwickler und ungefähr dreißig freiberufliche Entwickler beteiligt waren, sodass das Projekt immer noch zu 100% im Besitz von Netscape war.

Das Team kam zu dem Schluss, dass die Entwickler von außen nicht an dem Projekt interessiert waren, auch nicht wegen der Unordnung in der Codebasis:

Der Code erwies sich als zu kompliziert und verwirrend, um geändert zu werden, sodass die Leute keinen Beitrag leisteten ... Deshalb haben wir auf eine neue Engine umgestellt. Eine sauberere, frischere Codebasis, die einfacher zu verstehen ist und sich der Entwicklung anschließt.

Von Grund auf neu

So beschloss die Gruppe ein Jahr später, 5.0 aufzugeben, ohne eine Version zu veröffentlichen, und begann, Version 6.0 von Grund auf neu zu entwickeln.

Die Vorbereitung von Netscape 6.0 dauerte zwei ganze Jahre. und selbst nach all dem war klar, dass der Browser roh war. Laut David Pog, Kolumnist der New York Times , lief der Browser eine volle Minute (!) Und verbrauchte RAM. Es fehlten einige einfache Usability-Funktionen, die in früheren Versionen vorhanden waren:

Die Druckvorschau-Funktion sowie die Möglichkeit, das Symbol für die Site-Adresse direkt in das Lesezeichen-Menü zu ziehen, sind verschwunden. Sie können eine Webadresse auch nicht kopieren oder in die Adressleiste einfügen, indem Sie mit der rechten Maustaste darauf klicken. Und jedes Mal zu Beginn der Arbeit müssen Sie die Fenstergröße ändern: Navigator merkt sich nicht den vorherigen Status. Der unangenehmste Nachteil ist jedoch, dass Sie nicht die gesamte Adressleiste mit einem Klick auswählen können.

Das war jedoch fast irrelevant, da Internet Explorer in den drei Jahren, in denen Netscape stillstand, den verbleibenden Marktanteil eroberte:


Als die Browser-Verfeinerung begann, verlor Netscape schnell an Boden gegenüber Microsoft Internet Explorer. Der neue Browser kam drei Jahre später heraus, er war fehlerhaft und langsam; und der Marktanteil von Netscape fiel unterdessen auf fast Null (Grafik von Wikipedia angepasst)

1999, als die Neugestaltung des Browsers in vollem Gange war, erwarb AOL Netscape für 10 Milliarden US-Dollar. Nur zwei Jahre nach der Veröffentlichung von Netscape 6.0 wurde die AOL-Abteilung von Netscape liquidiert.

Mozilla, die von Netscape erstellte Open Source-Community, wird weiterhin bestehen und den Firefox-Browser im Jahr 2002 starten, ein weiteres Clean-Sheet-Projekt. Firefox hat es geschafft, einige der Benutzer, die Microsoft verlassen haben, zurückzugeben.

Aber Netscape als Unternehmen ist gestorben (Microsoft wird die Überreste des geistigen Eigentums von Netscape infolge eines 2012 mit AOL abgeschlossenen Vertrags begraben).

Nachdem Microsoft diesen Kampf gewonnen hatte, weigerte es sich, in Browsertechnologie zu investieren. Internet Explorer 6.0 wurde 2001 veröffentlicht und seit fünf Jahren nicht mehr aktualisiert. Einige halten dies für einen bewussten Versuch, die Werbung für das Internet als Plattform für Anwendungen zu blockieren.

Schlussfolgerungen

Einige glauben, dass das Umschreiben von Grund auf keine Katastrophe war. Dank dieser Tatsache erschienen schließlich die Gecko-Engine und der Firefox-Browser.

Aber wir alle mussten jahrelange Stagnation bei Webtechnologien unter dem endlosen, erstickenden Monopol von IE6 ertragen, während wir uns auf einen neuen Browser freuten, der der Branche Leben einhauchte. Und das Ende der IE6-Ära wurde nicht von Firefox, sondern von Google Chrome festgelegt.

In jedem Fall geht es nicht darum, wie sich das Projekt auf das Internet ausgewirkt hat. Es geht darum, was das Ergebnis für das Unternehmen ist. Der Tod von Netscape kann nicht auf diese Gründe zurückgeführt werden: Das Gericht stimmte zu, dass Microsoft sein Monopol absichtlich missbraucht hat. Aber natürlich war die Entscheidung, alles von Grund auf neu zu schreiben, ein wichtiger Faktor und führte zum Endergebnis: der Zerstörung eines Unternehmens im Wert von Milliarden von Dollar und Tausenden von Entlassungen. Daher stimme ich Joel zu, dass die Nettofolgen dieser Entscheidung katastrophal waren .

---

2. Basislager

In den frühen 2000er Jahren wurde das in Chicago ansässige Webdesign-Studio 37signals berühmt für seinen einflussreichen und oft kontroversen Blog , der von den Gründern Jason Fried und DHH mitbegründet wurde.

Als ich anfing, Webdesign zu machen, erregten sie meine Aufmerksamkeit mit einer Reihe von Artikeln mit Beispielen für falsches Design und Optionen, wie sie für Websites wie Google und PayPal neu erstellt werden können. Das Projekt wurde 37better genannt .




Die Neugestaltung des FedEx-Lieferformulars 37signals (oben) ist fast zwei Jahrzehnte später immer noch besser als das eigentliche Design

Das Unternehmen verfügte über ein Projektmanagementsystem für den internen Gebrauch , das 2004 als SaaS-Dienst namens Basecamp veröffentlicht wurde .

SaaS war zu dieser Zeit noch neu. Projektmanagement-Tools wurden in Kartons mit vierstelligen Preisschildern und gewichtigen Handbüchern verkauft. Sie alle arbeiteten am Konzept der Modellierung kritischer Pfade und zeichneten komplexe Gantt-Diagramme. Basecamp wurde für 50 US-Dollar im Monat verkauft und wurde mit seiner supereinfachen Benutzeroberfläche und dem Fokus auf Kommunikation zu einem Hauch frischer Luft.

Ein paar Jahre später hat Basecamp eine halbe Million zufriedene Benutzer, Zahlungen kommen jeden Monat an, aber Jason und David machten sich langsam Sorgen.

Vor einigen Jahren erzählte David diese Geschichte auf einer Business of Software- Konferenz. Er gab zu, dass er von Joel Spolsky beeinflusst wurde und glaubte, dass das Umschreiben von Software das Unternehmen töten würde. Darüber hinaus gab es im Zusammenhang mit der Popularität der Agilen Bewegung ein gewisses Element der Selbstzufriedenheit und Selbstgerechtigkeit:

[I] war völlig in die Idee der transzendentalen Software vertieft ... Ein unendlich flexibler Code. Unendlich wertvolles Erbe. Sie können alles ändern, jedes Programm, jeden Code neu schreiben ... Wenn die Software schwer zu ändern ist, sind Sie selbst schuld. Sie sind ein schlechter Programmierer, also müssen Sie sich verbessern.

Nach „sieben fetten Jahren“ befand sich das Unternehmen jedoch in einem Dilemma - und das Problem hatte nichts mit technischen Schulden zu tun .

Goldhandschellen

Alles begann damit, dass die Jungs einen Mangel an Begeisterung bemerkten. Es gab nicht nur nicht genug Motivation, an einem Flaggschiffprodukt zu arbeiten, sondern sie selbst nutzten ihr Programm nicht besonders.

Sie hatten viele Ideen, wie das Produkt grundlegend verbessert werden kann, aber jede Änderung wird die üblichen Arbeitsabläufe von Hunderttausenden von Basecamp-Benutzern stören. Das Problem lag nicht in der komplexen Codebasis, sondern in den Benutzern.

Aufgrund des Wunsches, bestehende Kunden zufrieden zu stellen, wurde das Produkt in der Entwicklung gestoppt, was die Gewinnung neuer Benutzer verhinderte. Dies bedrohte das Geschäft nicht direkt, stellte jedoch eine langfristige Bedrohung dar. DHH verglich die Situation metaphorisch mit einem undichten Eimer:

Sie können alle Löcher verschließen, alle Fehler beheben, alle Funktionen aktualisieren, über die sich bestehende Kunden beschweren - aber ein Teil des Wassers fließt immer heraus. Kunden verlassen die Arbeit und verlassen die Software, auch wenn sie sie mögen. Sie könnten irregeführt werden: „Hey, der Eimer ist mehr als halb voll. Es gibt nur ein kleines Loch, nur ein kleines Leck, es ist völlig natürlich. " Wenn die Situation jedoch weiterhin besteht, ist der Eimer vollständig leer.

Ein Teil des Problems besteht darin, dass Sie ständig auf aktuelle Kunden hören, aber keine zukünftigen:

Leute, die 2011 die Basecamp-Seite besuchten und sich weigerten, das Produkt zu kaufen, weil es nicht mehr zu ihnen passte: Wie denken Sie, wie oft haben wir auf ihre Meinung gehört? Niemals. Wir haben nur einer breiten Basis bestehender Kunden zugehört, die wirklich wollten, dass wir diese kleinen Löcher einfach weiter verschließen.

Entwickler begannen, ein profitables Produkt als ein Paar goldener Handschellen zu betrachten:

Die Hauptsache ist, sicherzustellen, dass alle aktuellen Benutzer zufrieden sind. Geld kommt jeden Monat, ein neuer Scheck, ein neuer Scheck, ein neuer Scheck. Großartig. Aber dann strecke die Hand aus und gebe zu: "Das war's, ich werde meine Software nie wieder ändern."

Spoiler: Basecamp wurde von Grund auf neu geschrieben und es hat sich als großartig herausgestellt. Es dauerte ungefähr ein Jahr und unmittelbar nach der Veröffentlichung von Basecamp 2 verdoppelte sich die Anzahl der Neuanmeldungen.

Ich denke, sie haben zwei Hauptsachen gemacht.

Erstens haben sie nicht versucht, das alte Produkt neu zu gestalten, sondern wollten zunächst neue Ideen umsetzen, wie die Probleme gelöst werden können, die das alte Produkt gelöst hat.

Sind wir so anmaßend zu glauben, dass die Ideen von 2003 immer noch die besten Ideen von 2011 sind? Ja, ich wurde der Arroganz beschuldigt, aber der ganze Dampf kam 2008 heraus.

Daher haben sie Basecamp 2 als völlig neues Produkt eingeführt, ohne Garantien, die mit Basecamp Classic abwärtskompatibel sind. Viele neue Dinge tauchten auf, etwas verschwand vollständig und vieles änderte sich vollständig.

Diese Entscheidung gab einen gewissen Freiheitsgrad. Freiheit motiviert und motivierte Menschen arbeiten besser.

Das Fehlen der Notwendigkeit, jede der Optionen für die Verwendung des Originalprodukts zu unterstützen, half. Mit dem ursprünglichen Basecamp konnten Sie beispielsweise Dokumente auf Ihrem eigenen FTP-Server hosten. Die Entwickler haben diese und ähnliche Funktionen entfernt, die früher sinnvoll waren, jetzt aber an den Rand gedrängt werden. Eine solche Reduzierung unnötiger Funktionen ermöglichte es, ein neues Produkt innerhalb einer angemessenen Zeit auf den Markt zu bringen.

Sonnenuntergang wird als schädlich angesehen

Aber was ist mit Hunderttausenden von bestehenden Benutzern, denen ihr Lieblingsspielzeug weggenommen wurde? Dies bringt uns zu der zweiten interessanten Sache, die die Entwickler gemacht haben: Sie haben das alte Produkt behalten .

David hatte eine großartige Fahrt mit dem Begriff "Sunset Software":

Jemand hat sich irgendwo einen schönen Euphemismus ausgedacht, der "Sonnenuntergang" genannt wird ... Nennen Sie die Zerstörung der Software "Sonnenuntergang" ... Wie alle Benutzer am Strand sind - und beobachten Sie mit Emotionen, dass ihre Informationen verschwinden. Das ist großartig!

Die einzigen Menschen, die an „Sonnenuntergang“ glauben, sind diejenigen, die es so nennen. Kein einziger Benutzer, der jemals wirklich die Sonnenuntergangsperiode durchgemacht hat, kommt zurück und sagt: "Oh, das war wunderschön." Sie kommen zurück und sagen: „Verdammt! Ich habe jahrelange Arbeit hierher gebracht! .. Und jetzt wirst du mich zusammenrollen ?! ”

Er merkte an, dass es der „schlimmste strategische Fehler“ ist, Menschen zum Packen und Bewegen zu zwingen, da Sie alle Stammkunden dazu zwingen, Entscheidungen zu treffen, Ihre Software weiterhin zu verwenden oder zu etwas anderem zu wechseln.

Benötige ich wirklich ein Basislager? Wenn Sie immer noch den gesamten Müll übertragen müssen, übertragen Sie ihn möglicherweise an einen anderen Ort. Wenn Sie Dinge in Kisten packen und in einen LKW laden müssen, kann ich diesen LKW einfach durch die Stadt schicken. Kein so großes Problem. Das große Problem ist das Packen des gesamten Manats. Und wo man wieder ins Basecamp oder an einen anderen Ort ziehen kann, ist ein zweitrangiges Thema.

David verglich den Basecamp Classic mit der Leica M3: Die Kamera wurde seit 1967 nicht mehr hergestellt, aber Leica verspricht, sie bis zum Ende seiner Tage zu warten und zu reparieren (Foto: Dnalor 01 ).

Stattdessen versprach Basecamp, „sein Erbe zu respektieren“ : Sie vereinfachten das Upgrade auf die neue Version, verlangten jedoch nicht, Basecamp Classic zu verlassen. Darüber hinaus haben sie sich verpflichtet, Basecamp Classic für immer beizubehalten.

Der Witz ist, dass sie es nach vier Jahren wieder getan haben: 2015 kam Basecamp 3 heraus, wieder neu geschrieben, mit einigen neuen Funktionen und ohne einige alte, und wieder hat sich viel geändert. Nach wie vor können Benutzer älterer Versionen problemlos ein Upgrade durchführen. Wenn sie möchten, können sie Basecamp Classic oder Basecamp 2 weiterhin "bis zum Ende des Internets" verwenden.

Basecamp 3 wird nichts rollen. Nicht die aktuelle Version, nicht die klassische Originalversion von Basecamp. Funktioniert eines davon gut für Sie? Cool! Bitte benutzen Sie es bis zum Ende des Internets! Wir sorgen dafür, dass die Programme schnell, sicher und immer zugänglich bleiben.

Aber es gibt viel "aber". Ist es nicht teuer? Ist die Unterstützung mehrerer Versionen sehr aufwändig? Was ist mit Sicherheit? Was ist mit veralteten Codebasen? Was soll ich sagen Wir kümmern uns nur um Kunden, auch wenn diese nicht gemäß unserem Zeitplan aktualisiert werden möchten.

Schlussfolgerungen

Persönlich scheint mir dieses Modell wirklich inspirierend zu sein.

Mit jeder Änderung konnte Basecamp zurückblicken und das Produkt erfahrungsgemäß neu gestalten. Für Benutzer ist dies ein Win-Win-Spiel: Konservative behalten ihr Spielzeug; und Innovatoren, die mit den Einschränkungen des Systems konfrontiert sind, erhalten eine neue und hoffentlich durchdachtere Anwendung.

Die Unterstützung mehrerer Versionen über einen unendlich langen Zeitraum hat natürlich ihren Preis. aber wie David sagt:

Es ist nicht kostenlos. Natürlich nicht. Dies ist ein wertvolles Produkt und natürlich ist der Support nicht kostenlos. Aber es lohnt sich.

---

3. Visual Studio & VS Code

Hinweis: Hipster-Symbol

Microsoft hat VS Code entwickelt, um Entwickler auf anderen Plattformen zu erreichen.

Sie müssen sich daran erinnern, dass Microsoft seit langem "alles oder nichts" angeboten hat. Wenn Sie Visual Studio verwendet haben, müssen Sie in .NET gearbeitet haben und umgekehrt. Dies teilte die Software-Community in zwei große, sich meist gegenseitig ausschließende Lager auf - zum Nachteil aller.

Appell an die coolen Jungs

Die Situation begann sich in den Jahren von Steve Ballmer zu ändern: Denken Sie daran, wie laut die Entscheidung der ASP.NET-Entwickler wurde, jQuery nicht zu erfinden !

Eine der Hauptaufgaben des CEO von Satya Nadella war es, die Entwickler außerhalb seines "eingezäunten Gartens" zu kontaktieren.

Aber es gab ein Problem. Julia Lewson, Vizepräsidentin von Visual Studio in dieser Ausgabe des Podcasts The Changelog, sagt Folgendes:

Wir konnten nicht eine ganze Klasse von Entwicklern anbieten: modern, weborientiert, die mit Node und JavaScript arbeiten - wir hatten einfach nichts, worüber wir mit ihnen sprechen konnten. Wir konnten diese Entwickler einfach nicht anziehen.

Also wurde der VS-Code erstellt, um diese Barriere zu durchbrechen und zu sagen: „Weißt du wirklich was, Leute? Wir haben noch etwas Nützliches für Sie. “

Visual Studio ist in jeder Hinsicht ein schweres Produkt: Nur die Installation kann mehr als eine halbe Stunde dauern. Es unterstützt eine Vielzahl komplexer Anwendungsfälle, auf die sich Unternehmenskunden verlassen. Daher war es sinnlos, Visual Studio als Ausgangspunkt zu nehmen und Funktionen in einem neuen Projekt auf anderen Plattformen hinzuzufügen . Und offensichtlich wurde die Idee, Visual Studio für Mac oder Linux zu veröffentlichen, nicht besonders unterstützt.

Daher hat Microsoft ohne Garantie der Abwärtskompatibilität von vorne begonnen.

Eigentlich nicht ganz von Grund auf neu: Microsoft hatte bereits einige wichtige Teile, wie den Monaco-Editor im Browser. Und da VS Code eine Node.js-Anwendung ist (in Typescript geschrieben und in Electron gestartet), haben sie die umfangreichen Ressourcen des JavaScript-Ökosystems genutzt.

Open Source VS Code, leicht, schnell und erweiterbar - überraschenderweise für ein Microsoft-Produkt - hat sich zu einem trendigen Programmiertool für fortgeschrittene Jugendliche entwickelt.


VS Code wurde zum Haupteditor für JS-Hipster (Diagramm aus dem Bericht State of JavaScript Survey, 2018 )

Beide Produkte befinden sich noch in der aktiven Entwicklung, und es gibt keinen Hinweis darauf, dass Microsoft beabsichtigt, Visual Studio zu schließen.

Schlussfolgerungen

Im Gegensatz zu Netscape ist es Microsoft wirklich gelungen, eine aktive Open Source-Community rund um VS Code zu erstellen. Es hat die Bemühungen der Entwickler verstärkt, das Produkt zu verbessern.


Von allen Open-Source-Projekten belegt Visual Studio Code den 13. Platz in Bezug auf die Anzahl der Sterne auf GitHub - zufällig knapp unter Linux!

Natürlich kann nicht jedes Unternehmen zulassen, dass sein Hauptprodukt frei verfügbar ist. Wenn Open Source jedoch Teil Ihrer Entwicklungsstrategie ist, ist es sinnvoll, die Geschichten von Microsoft und Netscape zu vergleichen - und herauszufinden, was Microsoft anders gemacht hat, damit seine Community floriert.

Ein weiterer wichtiger Faktor: Microsoft hat VS Code ein qualitativ hochwertiges Erweiterungsmodell zur Verfügung gestellt , aufgrund dessen die Community bereits etwa 10.000 Erweiterungen geschrieben hat.

Eine der letzten Schlussfolgerungen aus der Geschichte von VS Code ist, dass sich in den letzten Jahren alles dramatisch verändert hat: Heutzutage ist es einfacher als je zuvor, Prototypen und Software zu erstellen .

Trotz des Stöhnens über die Komplexität moderner Tools hat sich das JavaScript-Ökosystem in den letzten Jahren zu einem echten Open-Source-Modulparadies entwickelt. In dieser Hinsicht ist jetzt eine historisch beispiellose Zeit.

---

4. Google Mail und Posteingang

Hinweis: Das Sunset-Symbol

für den Posteingang für Google Mail wurde ursprünglich als alternatives minimalistisches UX für Google Mail eingeführt, "mit dem Fokus auf das, was wirklich wichtig ist". Er hat nie versucht, die Funktionalität des ursprünglichen Google Mail zu erreichen, und neue Funktionen eingeführt: thematische Gruppen (Bundles), angeheftete Briefe und ausstehende Nachrichten.

Einige Benutzer, einschließlich mir, haben den Posteingang begeistert angenommen. Ich habe immer gedacht, dass der Posteingang eine Demo dessen ist, was aus Google Mail letztendlich werden würde. Deshalb habe ich das Fehlen einiger Nuancen von Google Mail in Kauf genommen und erwartet, dass sie irgendwann in den Posteingang gelangen.

Zwei Schnittstellen, ein Dienst

Posteingang und Google Mail arbeiteten im selben Backend. Tatsächlich handelt es sich hierbei nur um unterschiedliche Benutzeroberflächen für denselben Dienst, und Sie können nach Belieben hin und her wechseln. Dies hatte seine Vor- und Nachteile: Wenn dem Posteingang eine Funktion fehlte (z. B. ein Anrufbeantworter für einen Urlaub), konnten Sie jederzeit zu Google Mail zurückkehren und konfigurieren, was Sie benötigen, obwohl das Hin- und Herwechseln seltsam erschien.

Nach einer Weile verbesserte sich der Posteingang jedoch nicht mehr - es wurde klar, dass Google keine Ressourcen mehr in ihn investierte. Natürlich kündigte Google vier Jahre nach dem Start den Sonnenuntergang des Posteingangs an .



Wie alle anderen war ich zuerst wütend auf eine solche Entscheidung. Nachdem ich einige Zeit mit der neuesten Version von Google Mail verbracht hatte, stellte ich fest, dass viele meiner bevorzugten Posteingangsfunktionen auf das Originalprodukt portiert wurden : eine intelligente Antwort, Hover-Aktionen, integrierte Anhänge und Bilder. Mehrere Google Mail-Postfächer ersetzen Posteingangs-Themengruppen ziemlich gut.

Aber nicht alles aus dem Posteingang wurde an Google Mail übertragen: Zum Beispiel sind die Leute so an den "Pausenmodus" (Schlafen) gewöhnt, dass sie ohne ihn jetzt buchstäblich körperlich leiden.

Schlussfolgerungen

Mit dem Posteingang konnten Google Mail-Entwickler mit Funktionen experimentieren, ohne den Workflow der meisten Benutzer zu stören .

Da jedoch beide Versionen im selben Backend bereitgestellt werden, hat Google Mail die Innovation stark eingeschränkt .

Wieder einmal wurde Google vielfach dafür kritisiert, dass es den beliebten Dienst geschlossen hat. Natürlich schließt Google seine Projekte ständig , also nichts Unerwartetes.

In diesem Fall hat uns die anfängliche Einstellung von Google gegenüber dem Posteingang zu der Annahme geführt, dass wir eine Demo der Zukunft von Google Mail haben. Wie DHH sagen würde, kam der Sonnenuntergang hässlich heraus: Viele Menschen fanden es unangenehm, zu einem alten Produkt zurückzukehren und die innovativen Workflows von Inbox zu verlieren.

Ich denke, dass für viele der Übergang viel einfacher gewesen wäre, wenn vor dem Schließen des Posteingangs alle Funktionen in Google Mail integriert worden wären.

---

5. FogBugz & Trello

Hinweis:

FogBugz ' Ikonen des traurigen Niedergangs und „Geld, Geld, Geld“ sind ein besonders interessanter Fall, da dies ein Produkt von Joel Spolsky selbst ist: Es gibt eine Vorstellung davon, wie das Prinzip „Niemals umschreiben“ mit dem wirklichen Leben konfrontiert wird.

Vor dem Aufkommen von Jira und GitHub gab es ein webbasiertes Ticket-Tracking-System namens FogBugz. Dieses im Jahr 2000 veröffentlichte System war das erste Produkt des neuen Unternehmens Fog Creek Software, das Joel zusammen mit Michael Prior gründete. Und seit mehr als einem Jahrzehnt ist FogBugz ihr Flaggschiff. Ursprünglich wurde es nur als Box-Version für die Installation auf eigenen Servern verkauft, später wurde jedoch eine SaaS-Option mit Abonnementzahlung veröffentlicht.

FogBugz ist sehr beliebt geworden, insbesondere bei Entwicklern, die in meinem Beispiel Joels Blog gelesen und sich seinen Rat zu Herzen genommen haben. Meine Firma hat das System viele Jahre lang benutzt, es war ein großartiges Produkt für seine Zeit.

FogBugz wurde ursprünglich auf dem klassischen ASP geschrieben, der auf Windows-Servern funktionierte. Als ASP.NET herauskam, erklärte Joel, warum er es nicht eilig hatte, ein Update durchzuführen .

Um FogBugz auf Linux-Servern zu installieren, hat ein Praktikant einen Thistle-Compiler geschrieben, um klassisches ASP in PHP zu konvertieren. Bis 2006 war Thistle zu einer proprietären Programmiersprache namens Wasabi herangewachsen, die in ASP, PHP und clientseitigem JavaScript kompiliert wurde.

Die seltsame Geschichte von Wasabi

Heutzutage ist die Entwicklung einer eigenen proprietären Programmiersprache und eines eigenen Compilers eine exzentrische Wahl. Es ist also interessant zu sehen, wie alles passiert ist.

An einem Punkt erwähnte Joel Wasabi in einem seiner Blog-Beiträge. Einige dachten, es sei ein Witz, also erklärte er , dass es kein Witz sei . Jeff Atwood, ein Blogger-Kollege, hat sich von diesen Neuigkeiten umgehauen :

Das Schreiben in Ihrer eigenen Sprache ist absolut unbegrenzt. Dies ist eine giftige Lösung, die so im Widerspruch zu Joels früheren hervorragenden und robusten Tipps zur Softwareentwicklung steht, dass die Leute wirklich dachten, er mache Witze.

Joel bestand darauf, dass die Entscheidung aus geschäftlicher Sicht sinnvoll sei. Theoretisch lohnt es sich natürlich nicht, eine eigene Sprache zu erfinden. Wenn Sie jedoch jeden kleinen Schritt in Richtung einer solchen Entscheidung angesichts des technologischen Kontexts und der Codebasis bewerten, erscheint alles logisch.

Der frühere Fog Creek-Ingenieur Ted Unangst reflektiert Wasabi in einem umfangreichen Aufsatz mit dem Titel „Technische Schulden und die Suche nach dem Wind“ und vergleicht den Prozess mit Reisen ohne Karte:

Stellen Sie sich vor, Sie befinden sich in Savannah, Georgia, und möchten nach London, England, fahren. Sie haben keine Karte, nur einen vagen Orientierungssinn ... Sie fahren nicht in einer geraden Linie, weil Sie kein Boot haben, sondern den Ozean vor sich. Andererseits führt ein angenehmer Strand nach Nordosten, und dies ist ungefähr die richtige Richtung. Sie gehen am Strand entlang, gehen und gehen. Die Zeit vergeht. Sie sehen, dass es mit jedem Schritt dem Ziel näher kommt, obwohl Sie sich nicht direkt darauf zubewegen.

Irgendwo in Boston oder in Nova Scotia halten Sie endlich an und denken über Ihre Wahl nach. Vielleicht führt diese Straße nicht nach London? Weit entfernt von der Galerie hört man Gelächter: „Ha ha ha, sieh dir diese Idioten an. Sie sehen keinen Unterschied zwischen England und Neuengland. Gib diesen Dummköpfen eine Karte. “ Aber genau das ist das Problem: Sie haben keine Karte. Karten werden von Personen erstellt, die per Definition nicht wissen, wohin sie gehen.

Auf jeden Fall, erklärt Jacob Krall, ein weiterer ehemaliger Fog Creek-Entwickler, hat die Lösung die Wartbarkeit von morgen für die heutige Entwicklungsgeschwindigkeit geopfert. Und bis 2010 kamen Konten für diese Schulden an.

Wir haben [Wasabi] nicht in Open Source integriert, daher sind uns die Kosten allein aufgrund unserer wichtigsten profitablen Produkte entstanden ... Es war eine enorme Abhängigkeit, die einen permanenten Entwickler für dieses Produkt allein erforderte: nicht billig für ein Unternehmen unserer Größe. Manchmal verfluchte der Compiler einen Code, der für eine Person durchaus vernünftig aussah. Er stellte langsam zusammen. Visual Studio konnte den Debugger nicht einfach bearbeiten oder mit FogBugz verbinden ... Alle neuen Mitarbeiter wurden unabhängig von ihren bisherigen Erfahrungen zunächst lange Zeit von Wasabi geschult ... Außerdem lebten wir nicht in einem Vakuum. Außerhalb von Fog Creek haben sich die Programmiersprachen natürlich verbessert ... Entwickler haben das Gefühl, dass ihre brillanten Ideen mit den Einschränkungen unseres kleinen Wasabi-Universums konfrontiert sind.

Wendepunkt

Zu diesem Zeitpunkt war FogBugz bereits zehn Jahre alt: Es war ein ausgereiftes und stabiles Produkt. Als Nebenprojekt startete Joel Stack Overflow zusammen mit Jeff Atwood (offensichtlich hatte Jeffs geblasener Kopf es bis dahin geschafft, zu heilen).

FogBugz altert allmählich. Obwohl der Bug-Tracker-Markt weiterhin fragmentiert war, trat Atlassians Jira, der einige Jahre nach FogBugz herauskam, in den Vordergrund. Dies ist die Standardauswahl, insbesondere für große Unternehmensbenutzer.

Es ist wirklich interessant, diesen besonderen Wendepunkt in der Geschichte von FogBugz zu betrachten. Wie Basecamp hatten sie ein profitables, ausgereiftes Produkt. Ja, es ist nicht mehr so ​​in Mode und vielleicht war es nicht sehr interessant, daran zu arbeiten. Ob gut oder schlecht, es beinhaltet viele Jahre des technologischen Wandels und neue Ideen zur Lösung eines bestimmten Problems: das Verfolgen von Fehlern.

Natürlich gab es eine Basecamp-Option: Berücksichtigen Sie alle Erfahrungen und nehmen Sie FogBugz von Grund auf neu und schreiben Sie es neu. Ich nehme an, diese Idee ist nicht zu weit gegangen, weil wir uns erinnern: „Was kann man nie tun?“, „Der schlimmste strategische Fehler“ und so weiter und so fort.

Ich bin kürzlich auf einen Artikel von 2009 aufmerksam geworden, den Joel für Inc. geschrieben hat. Magazin Die Kolumne seines Autors mit dem Titel "Bedeutet langsames Wachstum langsamen Tod?" Sein Ton ist völlig anders als gewöhnlicher selbstbewusster Pomp: Er klingt introspektiv, unsicher und voller Zweifel. Joel macht sich Sorgen über das schnelle Wachstum von Atlassian und diskutiert, ob auf dem Markt Platz für mehrere Spieler ist.

Ich musste nachdenken. Wir haben einen großen Konkurrenten, der viel schneller wächst als wir. Das Unternehmen schließt große Geschäfte mit großen Firmenkunden ab ... Mittlerweile ist unser Produkt viel besser und wir sind ein gut geführtes Unternehmen, aber das scheint keine Rolle zu spielen. Warum?

Er beschließt, zwei Dinge zu tun. Fügen Sie zunächst alle Funktionen zu FogBugz hinzu :

Die Aufgabe des Entwicklungsteams für 2010 ist es, jeden möglichen Grund zu beseitigen, warum Kunden Müll von unseren Mitbewerbern kaufen können, nur weil es eine kleine Funktion gibt, ohne die sie angeblich absolut nicht leben können. Ehrlich gesagt denke ich nicht, dass es sehr schwierig sein wird.

Zweitens erstellen Sie ein Unternehmensvertriebsteam . Joel gibt zu, dass er hier nicht stark ist und findet diese Aufgabe unangenehm.

Ich weiß nicht, wie diese Maßnahmen funktioniert haben. Joel erwähnte FogBugz zuletzt im Mai 2010 in seinem Blog und kündigte kurz eine neue Version an.

Neue Hoffnung

Und genau das ist passiert:

Im Bereich des zehnjährigen Jubiläums von Fog Creek Software begann ich zu denken: Um unsere Mitarbeiter für weitere zehn Jahre motiviert zu halten, müssen wir mit der Arbeit an etwas Neuem beginnen.

Daher wurden sie in zwei Teams aufgeteilt, von denen jedes einen Prototyp eines neuen Produkts herstellte. Die Gewinneridee wurde im Geiste eines Kanban-Boards entwickelt - eines echten Offline-Boards, das häufig in Softwareentwicklungsprojekten verwendet wird: Es sieht normalerweise aus wie Notizen, die in Spalten auf einem Board angeordnet sind.

Joel führte dieses Programm als Management-Tool auf einer höheren Ebene als FogBugz ein:

Ehrlich gesagt, mit all dieser ausgefallenen Software für das „Projektmanagement“ konnte ich nie richtig verfolgen, wer an was arbeitet ... Als Gründer von zwei Unternehmen ging ich die Korridore entlang und sah Dutzende von Menschen, die dafür bezahlt werden, an Computern zu sitzen ... und ich hatte keine Ahnung, ob sie ihre Arbeit richtig machten oder ob sie es für wichtig hielten, was eigentlich nicht wichtig sein könnte.

Bei der Entwicklung von Trello hatten die Entwickler von Fog Creek die Möglichkeit, moderne Technologien einzusetzen:

Wir verwenden fortschrittliche Technologie, daher ist dies nicht ohne Opfer. Unsere Entwicklerwunden sind in MongoDB, WebSockets, CoffeeScript und Node verteilt. Aber jetzt sind sie interessiert. Auf dem heutigen geschäftigen Arbeitsmarkt entscheiden talentierte Programmierer viel darüber, woran sie arbeiten möchten. Wenn Sie ihnen ein interessantes Produkt geben ... werden sie es mögen und sie werden ihre Gesellschaft lieben.

Trello unterstützte Plugins von Anfang an, daher begannen Entwickler von Drittanbietern zu helfen:

Plugins und APIs haben die höchste Priorität ... Machen Sie niemals selbst ein Produkt, wenn Sie eine grundlegende API bereitstellen können, und wertvolle Benutzer ... werden es für Sie machen. Für das Trello-Team gilt die Regel, dass Funktionen, die über ein Plug-In implementiert werden können, auf diese Weise implementiert werden müssen.

Programmierer haben natürlich sofort die Vorteile von Trello verstanden, aber das Tool für die Entwicklung spezifischer Software enthielt nichts Spezielles. Joel beschrieb Trello als nützliches Werkzeug für "alles, wo Sie Listen mit anderen Menschen teilen möchten". Bald begann Trello, alles hintereinander zu organisieren: von wöchentlichen Abendessen bis zu Hochzeiten und Hundehütten .

Während FogBugz ein vertikales Produkt war, das sich an einer bestimmten Marktnische orientierte, war Trello ein horizontales Produkt, das für alles geeignet war. Joel hält Fog Creeks "horizontale Bewegung" an diesem Punkt für richtig:

Es ist fast unmöglich, ein großes horizontales Produkt zu erstellen, das in allen Bereichen nützlich ist. Es kann nicht teuer sein, weil Sie mit anderen horizontalen Produkten konkurrieren, die Ihre Entwicklungskosten für eine große Anzahl von Benutzern absorbieren können. Dies ist ein hohes Risiko und eine hohe Belohnung: Dieser Weg ist nicht für ein junges Startup geeignet, aber eine gute Idee für ein zweites oder drittes Produkt eines reifen und stabilen Unternehmens wie Fog Creek.

Um schnell auf eine sehr große Anzahl von Benutzern skaliert zu werden, wurde Trello zunächst kostenlos angeboten. Später wurde ein Geschäftsplan eingeführt.

Im Jahr 2014 wurde Trello als unabhängiges Unternehmen ausgezeichnet. Drei Jahre später verkaufte es sich mit mehr als 17 Millionen Nutzern über 425 Millionen US- Dollar. Ironischerweise war der Käufer Atlassian, der alte vereidigte Feind von Fog Creek.

In der Zwischenzeit kehren wir nach Hause zurück ...

Fog Creek entwickelte ein weiteres neues Produkt, eine kollaborative Programmierumgebung namens HyperDev , die später in GoMix und dann in Glitch umbenannt wurde .

Gleichzeitig erstarrte das FogBugz-System im Dunkeln. Im Jahr 2017 entschied jemand, dass FogBugz ein alberner Name ist, und der technische Aufwand ging in die Umbenennung des Produkts in Manuskript . Ein Jahr später - noch vor wenigen Monaten - verkaufte Fog Creek das Produkt an eine kleine Firma DevFactory , die sofort den Namen FogBugz zurückgab .

Unter der Führung von CEO Anil Dash wurde Fog Creek ein Einzelproduktunternehmen und änderte seinen Namen in Glitch .

Schlussfolgerungen

Ich habe viele Gedanken darüber.

Der Schlüssel zum Verständnis der Geschichte liegt darin, dass es Fog Creek immer weniger um Fehlerverfolgung als vielmehr um die Befähigung von Programmierern ging - beginnend mit seiner eigenen:

Die Hauptaufgabe: Schaffung komfortabler Arbeitsbedingungen. Wir haben persönliche Konten für die Mitarbeiter erstellt, sie sind nur in der ersten Klasse geflogen, haben 40 Stunden pro Woche gearbeitet, haben ein kostenloses Mittagessen, Aeron-Stühle und die besten Computer erhalten. Wir haben unsere geniale Formel mit der Welt geteilt: hervorragende Arbeitsbedingungen → hervorragende Programmierer → hervorragende Software → Gewinn!

Basierend auf dieser „Formel“ kann eine logische und ermutigende Schlussfolgerung gezogen werden: Fog Creek baute ein Geschäft um das Glück der Entwickler auf. Dies betraf sowohl die Produkte des Unternehmens als auch das interne „Betriebssystem“ . Das erste Produkt, ein Bug-Tracker, diente als Grundlage für die Einführung eines neuen Produkts, das ein ähnliches Problem abstrakter löste.

Laut Joel scheint die Geschichte von Trello weniger eine Suche nach einem neuen Geschäft als vielmehr eine Möglichkeit zu sein, die Motivation und das Engagement der Entwickler von Fog Creek zu unterstützen . Ein Produkt im Wert von einer halben Milliarde Dollar war nur ein angenehmer Nebeneffekt.

Ein bisschen traurig, wie alles für FogBugz endete. Ich glaube nicht, dass die Entwickler von Fog Creek in den letzten Tagen vor dem Verkauf besonders glücklich waren.

Es ist klar, dass es wichtigere und größere Projekte gab: Stack Overflow, Trello und Glitch - jedes einzeln ist viel nützlicher und wertvoller als FogBugz; und es ist unmöglich, dass eine Person alles im Auge behält. Daher kann ich insbesondere niemanden für den Verlust des Interesses an FogBugz mit einer 20-jährigen Codebasis und einem starken Wettbewerb auf dem Markt verantwortlich machen. Aber treue Benutzer fanden zumindest ein gutes Zuhause und erhielten keine Sonnenuntergangsmedizin!

Der sentimentale Teil von mir würde es jedoch vorziehen, das Erbe aller, die an der Entwicklung und Verwendung dieses Produkts in den letzten Jahren beteiligt waren, ehrenhafter zu „ehren“.

---

6. FreshBooks und BillSpring

Hinweis: Symbol für verdeckte Operationen

Der Artikel ist mehr gewachsen als ich erwartet hatte, aber ich kann diese Geschichte nicht beiseite lassen. Warte, es wird eine unerwartete Wendung geben.

Hör auf mich, wenn du es schon mal gehört hast

In den frühen 2000er Jahren hatte Mike McDerment eine kleine Designfirma. Er entschied, dass die Buchhaltungssoftware zu kompliziert war, und verwendete daher Word und Excel für die Abrechnung.

Bis zu einem Fall hat alles gut funktioniert:

Der kritische Moment kam, als nur der Fall eine wichtige Kundenrechnung speicherte - ich klickte einfach auf die gewünschte Schaltfläche. Ich wusste, dass es einen besseren Weg geben musste, also verbrachte ich die nächsten zwei Wochen damit, einen Prototyp zu programmieren, der die Grundlage für die heutigen FreshBooks bilden würde.

Mike ist ein Designer, kein Programmierer, aber er und die beiden Mitbegründer haben es geschafft, ein Tool zusammenzustellen, das gut genug ist, damit mehrere Leute 10 US-Dollar pro Monat dafür bezahlen können. Es dauerte fast vier Jahre, bis das Unternehmen den Keller des Elternhauses verlassen hatte.

Bis zum 10. Jahrestag des Programms (kommt Ihnen das bekannt vor?) Ist Freshbooks ein profitables Unternehmen mit über 10 Millionen Benutzern und 300 Mitarbeitern geworden.

Aber es gab ein Problem. Als es dem Unternehmen gelang, „echte“ Programmierer einzustellen, verfügten sie über eine Million Zeilen „Gründercode“. Ein externer Analyst überprüfte die Codebasis und kam zu dem Schluss:

„Die gute Nachricht ist, dass Sie die schwierigste Aufgabe gelöst haben. Sie haben herausgefunden, wie man ein Geschäft aufbaut, und Sie haben ein Produkt, das den Leuten gefällt. Die schlechte Nachricht ist, dass ihr euch mit Technologie schlecht auskennt . “

Noch wichtiger war, dass es unmöglich war, die vorhandenen Ideen in ein vorhandenes Produkt umzusetzen:

Wir haben das Unternehmen vor mehr als zehn Jahren gegründet, die Welt hat sich verändert und wir haben viel über die Entwicklung von Programmen und die Bedürfnisse einzelner Unternehmer gelernt, die in der Gesellschaft immer mehr werden. Wir wussten, dass einige Anstrengungen unternommen werden mussten, um FreshBooks in fünf Jahren auf dem neuesten Stand zu halten.

MacDerment ist mit der herkömmlichen Weisheit vertraut, dass Sie ein System nicht von Grund auf neu schreiben können:

Das Umschreiben von Code von Grund auf ist das größte Risiko für ein Softwareunternehmen. Höchstwahrscheinlich werden Sie das Projekt noch nicht einmal beenden. Es wird mehr Zeit als geplant dauern und mehr kosten. Das Endergebnis spricht Kunden möglicherweise nicht an. Und es gibt keine Garantie dafür, dass die neue Plattform tatsächlich besser ist als die vorherige. Die Regel Nummer eins in Software ist, Ihre Software nicht neu zu schreiben.

Daher unternahmen sie mehrere Versuche, das Chaos zu beseitigen, ohne das System von Grund auf neu zu schreiben. Ein „Reifenwechsel unterwegs“ war jedoch nicht möglich.

Was als nächstes geschah, kann Sie überraschen

McDermint wurde von der Idee besucht, heimlich ein "Konkurrent" FreshBooks zu schaffen.

Er gründete in Delaware eine völlig neue Firma namens BillSpring. Sie hatte ihre eigene Website, Marke und Logo. Er versuchte, die beiden Unternehmen nicht miteinander zu verbinden, und wies einen externen Anwalt an, neue Dokumente für sie zu entwickeln.

Das Entwicklungsteam hat flexible Entwicklungspraktiken implementiert, die auf dem Buch von Jeff Gottelf und Josh Seiden „Lean UX: Entwerfen großartiger Produkte mit flexiblen Teams“ basieren: Scrum-Teams und wöchentliche Iterationen mit Feedback von echten Kunden. MacDerment bat sie, sich wie ein Startup zu verhalten und ihn als Risikoinvestor zu nehmen:

„Du hast viereinhalb Monate Zeit. Wenn Sie in den Markt eintreten, erhalten Sie mehr Geld. Ansonsten das Ende. "

Das Team konnte MVP einige Tage vor Ablauf der Frist veröffentlichen. Sie kauften AdWords-Keywords, um den Traffic zu steigern, und boten den Nutzern im ersten Jahr kostenlose Konten an. Bald erschienen Kunden - und es begannen schnelle Iterationszyklen des realen Produkts.

Am Ende des ersten Jahres begann BillSpring mit dem Aufladen. Irgendwann erhielt das neue Produkt eine unerwartete Bewertung der Qualität :

"Eine Person hat angerufen, um sich von FreshBooks abzumelden und zu unserer neuen Firma zu gehen", sagt McDermint. "Es war ein großartiger Tag."

Bald lösten sie den Schleier der Geheimhaltung und informierten BillSpring-Kunden darüber, dass es sich um ein FreshBooks-Produkt handelt, und sie informierten bestehende FreshBooks-Kunden darüber, dass bald eine neue Version kommen würde.

Allmählich wurden Kunden der „klassischen“ FreshBooks zur neuen Version zugelassen, konnten aber jederzeit zur alten zurückkehren, wenn sie wollten.

Schlussfolgerungen

Das geheime FreshBooks-Projekt war nicht billig: Laut McDermint gaben sie 7 Millionen US-Dollar dafür aus. Nach mehr als einem Jahrzehnt Wachstum allein mit eigenen Mitteln sammelten sie jedoch 30 Millionen US-Dollar Risikokapital, sodass es Geld gab. Nicht jeder kann es sich leisten.

Forbes schätzte den Umsatz von FreshBooks im Jahr 2013 auf 20 Millionen US-Dollar. Nach Abschluss des Updates im Jahr 2017 verdienten sie 50 Millionen US-Dollar. Es ist nicht bekannt, wie viel von dem neuen Produkt kam, aber das Schreiben des Systems von Grund auf hat das Wachstum des Unternehmens eindeutig nicht gebremst.

Laut MacDerment ist der Prozess der Entwicklung und Implementierung neuer Funktionen schneller und einfacher geworden. Noch wichtiger ist, dass sie jetzt ein Produkt in der Hand haben, das die besten Ideen umsetzt. Damit hat man keine Angst in die Zukunft zu schauen.

Darüber hinaus haben die gesammelten Erfahrungen die Unternehmenskultur auf gute Weise verändert. Als sie vorgaben, ein Startup zu sein, lernten sie, wie man als Startup arbeitet. Lean UX-Praktiken haben sich auf das gesamte Entwicklungsteam ausgeweitet. Kunden sind aktiv an der Entwicklung neuer Funktionen beteiligt.

FreshBooks hat außergewöhnliche Maßnahmen ergriffen, um sich vor potenziellen Problemen zu schützen: Durch die Einführung von Innovationen unter der Marke Fake konnten Entwickler das Programm völlig überdenken und große Risiken eingehen. Selbst im schlimmsten Fall schaden sie der bestehenden Marke nicht.

Es scheint alles ein bisschen extrem. Vielleicht waren solche Maßnahmen nicht notwendig. Dies ist jedoch eine Erinnerung daran, wie ernst die Einsätze sind.

---

Einige Gedanken

Es ist allgemein anerkannt, dass es besser ist, ein Umschreiben eines Programms von Grund auf zu vermeiden und wenn möglich schrittweise Verbesserungen vorzunehmen. Dem stimme ich größtenteils zu.

Der Ratschlag deutet jedoch darauf hin, dass wir am Ende ein Originalprodukt sowie eine Reihe neuer Funktionen erhalten.

Aber was ist, wenn Sie Funktionen entfernen möchten? Oder eine Option ganz anders implementieren? Was wäre, wenn die Erfahrung mit den Ideen eines grundlegend neuen Ansatzes einhergehen würde?

Mein Fazit aus diesen Geschichten lautet: Sobald Sie verstehen, dass sich die aktuelle Version stark vom imaginären Ideal unterscheidet , sollte die neue Version nicht als Ersatz veröffentlicht werden, sondern parallel zur aktuellen .

Wenn es Gedanken gibt, alles von Grund auf neu zu schreiben, sollten Sie vielleicht andere Fragen stellen. Vielleicht einen eigenen Konkurrenten erstellen? Wenn mein Produkt FogBugz ist, was ist dann mein Trello? Wenn dies Visual Studio ist, wie sieht mein VS-Code aus?

Wenn wir Spolskys Artikel über Netscape und den DHH-Beitrag über Basecamp vergleichen, sind sie sich in einer Sache einig: Vermächtnis hat Wert.

Die gute Nachricht ist, dass Sie diesen Wert nicht wegwerfen müssen, um innovativ zu sein.