Un nouveau regard sur la question séculaire: l'application doit-elle être réécrite à partir de zéro ou est-ce «la pire erreur stratégique qu'un développeur de logiciels peut faire»? Il s'avère que lorsque vous travaillez avec une base de code mature, il existe plus de deux options de réponse.

"Le code source semble rouillé !" - Joel Spolsky

Il y a près de deux décennies, Joel Spolsky a mis en scène Netscape pour avoir réécrit la base de code du navigateur dans son essai épique «What You Can Never Do» . Il en est venu à la conclusion que les logiciels fonctionnels ne devraient jamais être réécrits à partir de zéro . Il avait deux arguments principaux:

• Les parties de la base de code qui ressemblent à des ordures incluent souvent des connaissances durement acquises sur les situations de frontière et les bogues étranges.
  
• La modification complète est une entreprise à long terme qui distrait de l'amélioration du produit existant, ce qui donne des atouts aux concurrents.

Pour beaucoup, les découvertes de Joel sont devenues un dogme; à un moment donné, ils m'ont beaucoup influencé. Mais dans les années suivantes, j'ai réalisé que dans certaines circonstances, il était toujours logique de refaire complètement le produit. Par exemple:

• Parfois, une base de code obsolète n'est vraiment pas récupérable, donc même une simple mise à niveau nécessite des modifications en cascade dans d'autres parties du code.
  
• Les solutions technologiques originales peuvent interférer avec les améliorations nécessaires.
  
• Ou, la technologie d'origine peut être obsolète, ce qui rend difficile (ou trop cher) l'embauche de développeurs qualifiés.

Bien sûr, en fait, beaucoup dépend des circonstances. Oui, il est parfois judicieux de remanier progressivement le code obsolète. Et oui, parfois, il est logique de tout jeter et de recommencer.

Mais ce n'est pas le seul choix . Jetons un coup d'œil à six histoires et voyons quelles leçons peuvent être apprises.

---

1. Netscape

Le code du navigateur a été réécrit trois fois à partir de zéro

La transition catastrophique de Netscape de 5.0 à 6.0 a été l'occasion de l'article susmentionné de Joel Spolsky et beaucoup sont convaincus que cela ne devrait jamais être fait.

Netscape Navigator est sorti en 1994, dans les premières années de l'Internet commercial. Deux ans plus tard, la société a ouvert l'ère du dot-com avec une introduction en bourse de 3 milliards de dollars.

Le premier concurrent majeur de Netscape a été Microsoft Internet Explorer, sorti en 1996.

Au début de 1998, Netscape était toujours le premier navigateur, mais avec beaucoup de difficultés. Netscape était un programme commercial vendu 49 $, et Microsoft a distribué IE gratuitement et livré comme navigateur par défaut sous Windows.



Avec la sortie de Netscape 4.0, la société a annoncé que la prochaine version sera gratuite et sera développée par la communauté open source, créée et financée par Mozilla. Pour l'époque, c'était essentiellement une décision sans précédent, et Netscape a gagné beaucoup de partisans pour une décision aussi audacieuse. Mais en réalité, cette «communauté» ne s'est pas concrétisée. Jamie Zawinski, l'un des premiers développeurs de navigateurs, explique :

La vérité est que le projet Mozilla impliquait une centaine de développeurs Netscape à temps plein et une trentaine de développeurs indépendants, de sorte que le projet appartenait toujours entièrement à Netscape.

L'équipe est parvenue à la conclusion que les développeurs de l'extérieur n'étaient pas intéressés par le projet, notamment à cause du désordre dans la base de code:

Le code s'est avéré trop compliqué et déroutant pour changer, donc les gens n'ont pas contribué ... C'est pourquoi nous sommes passés à un nouveau moteur. Une base de code plus propre et plus fraîche qui est plus facile à comprendre et à rejoindre le développement.

À partir de zéro

Ainsi, un an plus tard, le groupe a décidé d'abandonner la version 5.0 sans publier de version et a commencé à développer la version 6.0 à partir de zéro.

La préparation de Netscape 6.0 a pris deux années entières; et même après tout cela, il était clair que le navigateur était brut. Selon le chroniqueur du New York Times David Pog, le navigateur a fonctionné pendant une minute (!) Et a consommé de la RAM. Il manquait un certain nombre de fonctionnalités simples d'utilisation qui étaient dans les versions précédentes:

La fonction d'aperçu avant impression a disparu, ainsi que la possibilité de faire glisser l'icône d'adresse du site directement dans le menu des signets. De plus, vous ne pouvez pas copier ou coller une adresse Web dans la barre d'adresse en cliquant dessus avec le bouton droit. Et à chaque fois au début du travail, vous devez changer la taille de la fenêtre: Navigator ne se souvient pas de l'état précédent. Mais l'inconvénient le plus désagréable est que vous ne pouvez pas sélectionner toute la barre d'adresse en un seul clic.

Mais c'était presque hors de propos, car au cours des trois années où Netscape s'est arrêté, Internet Explorer a capturé la part de marché restante:


Lorsque le raffinage du navigateur a commencé, Netscape a rapidement perdu du terrain au profit de Microsoft Internet Explorer. Le nouveau navigateur est sorti trois ans plus tard, il était buggé et lent; et la part de marché de Netscape, quant à elle, est tombée à presque zéro (graphique adapté de Wikipedia )

En 1999, alors que la refonte du navigateur battait son plein, AOL a acquis Netscape pour 10 milliards de dollars. Deux ans seulement après la sortie de Netscape 6.0, la division AOL de Netscape a été liquidée.

Mozilla, la communauté open source créée par Netscape, continuera d'exister et lancera le navigateur Firefox en 2002, un autre projet de feuille blanche. Firefox a réussi à renvoyer certains des utilisateurs qui sont partis à Microsoft.

Mais Netscape, en tant qu'entreprise, est décédée (Microsoft enterrera les restes de la propriété intellectuelle de Netscape à la suite d'un accord de 2012 avec AOL).

Ayant remporté cette bataille, Microsoft a refusé d'investir dans la technologie des navigateurs. Internet Explorer 6.0 est sorti en 2001 et n'a pas été mis à jour depuis cinq ans . Certains considèrent cela comme une tentative délibérée de bloquer la promotion d'Internet en tant que plate-forme d'applications.

Conclusions

Certains pensent que la réécriture à partir de zéro n'était pas un désastre. Au final, grâce à cela, le moteur Gecko et le navigateur Firefox sont finalement apparus.

Mais nous avons tous dû endurer des années de stagnation dans les technologies Web sous le monopole éternel et étouffant d'IE6 , alors que nous attendions avec impatience un nouveau navigateur qui donnerait vie à l'industrie. Et la fin de l'ère IE6 n'a pas été mise par Firefox, mais Google Chrome.

En tout cas, il ne s'agit pas de savoir comment le projet a affecté Internet. Il s'agit du résultat pour l'entreprise. La mort de Netscape ne peut être imputée à ces raisons: le tribunal a reconnu que Microsoft avait intentionnellement abusé de son monopole. Mais bien sûr, la décision de tout réécrire à partir de zéro a été un facteur important et a conduit au résultat final: la destruction d'une entreprise valant des milliards de dollars et des milliers de licenciements. Par conséquent, je conviens avec Joel que les conséquences nettes de cette décision ont été désastreuses .

---

2. Basecamp

Au début des années 2000, le studio de conception de sites Web de Chicago appelé 37signals est devenu célèbre pour son blog influent et souvent controversé, cofondé par les fondateurs Jason Fried et DHH .

Lorsque j'ai commencé à faire de la conception Web, ils ont attiré mon attention avec une série d'articles avec des exemples de conception incorrecte et des options pour les refaire pour des sites tels que Google et PayPal. Le projet s'appelait 37better .




La refonte du formulaire de livraison FedEx 37signals (ci-dessus) est toujours meilleure que la conception réelle , près de deux décennies plus tard

L'entreprise disposait d' un système de gestion de projet à usage interne , qu'elle a lancé en 2004 sous la forme d'un service SaaS appelé Basecamp .

Le SaaS était encore nouveau à l'époque. Les outils de gestion de projet ont été vendus dans des boîtes avec des étiquettes de prix à quatre chiffres et des manuels lourds. Ils ont tous travaillé sur le concept de modélisation des chemins critiques et dessiné des diagrammes de Gantt complexes. Basecamp s'est vendu pour 50 $ par mois et est devenu une bouffée d'air frais avec son interface super simple et l'accent mis sur la communication.

Avance rapide de quelques années, Basecamp compte un demi-million d'utilisateurs satisfaits, les paiements arrivent chaque mois, mais Jason et David ont commencé à s'inquiéter.

Il y a quelques années, David a raconté cette histoire lors d'une conférence Business of Software . Il a admis qu'il était influencé par Joel Spolsky et pensait que le logiciel de réécriture tuerait l'entreprise. De plus, il y avait un certain élément de complaisance et d'autosatisfaction en lien avec la popularité du mouvement Agile:

[I] était complètement absorbé par l'idée d'un logiciel transcendant ... Code infiniment plastique. Un héritage infiniment précieux. Vous pouvez tout changer, réécrire n'importe quel programme, n'importe quel code ... Si le logiciel est difficile à changer, c'est votre faute. Vous êtes un mauvais programmeur, vous devez donc vous améliorer.

Cependant, après «sept grosses années», l'entreprise s'est retrouvée dans un dilemme - et le problème n'avait rien à voir avec la dette technique .

Menottes en or

Tout a commencé avec le fait que les gars ont remarqué un manque d'enthousiasme. Non seulement il n'y avait pas assez de motivation pour travailler sur un produit phare, mais eux-mêmes n'utilisaient pas particulièrement leur programme.

Ils avaient beaucoup d'idées sur la façon d'améliorer fondamentalement le produit, mais tout changement perturbera les flux de travail habituels de centaines de milliers d'utilisateurs de Basecamp. Le problème n'était pas dans la base de code complexe, mais dans les utilisateurs.

En raison de la volonté de satisfaire les clients existants, le produit s'est arrêté de développement, ce qui a empêché d'attirer de nouveaux utilisateurs. Cela ne menaçait pas directement l'entreprise, mais constituait une menace à long terme. DHH a comparé métaphoriquement la situation avec un seau qui fuit:

Vous pouvez boucher tous les trous, corriger toutes les erreurs, mettre à jour toutes les fonctions dont se plaignent les clients existants - mais une partie de l'eau s'écoule toujours. Les clients quittent le travail et quittent le logiciel, même s'ils [l'aiment]. Vous pourriez être induit en erreur: «Hé, le seau est plus qu'à moitié plein. Il n'y a qu'un petit trou, juste une petite fuite, c'est tout à fait naturel. " Mais, si la situation persiste, le seau sera complètement vide.

Une partie du problème est que vous écoutez constamment les clients actuels, mais n'entendez pas les futurs:

Les personnes qui ont visité la page Basecamp en 2011 et ont refusé d'acheter le produit car il ne leur convenait plus: comment pensez-vous, à quelle fréquence avons-nous écouté leur avis? Jamais. Nous n'avons écouté qu'une large base de clients existants qui voulaient vraiment que nous continuions à boucher ces petits trous.

Les développeurs ont commencé à considérer un produit rentable comme une paire de menottes en or:

L'essentiel est de s'assurer que tous les utilisateurs actuels sont satisfaits. L'argent vient chaque mois, un nouveau chèque, un nouveau chèque, un nouveau chèque. Super. Mais ensuite, tendez la main et admettez: «Voilà, je ne changerai plus jamais mon logiciel.»

Spoiler: Basecamp a été réécrit à partir de zéro, et cela s'est avéré super. Cela a pris environ un an, et immédiatement après la sortie de Basecamp 2, le nombre de nouvelles inscriptions a doublé.

Je pense qu'ils ont fait deux choses principales.

Premièrement, ils n'ont pas essayé de refaire l'ancien produit - parce qu'ils voulaient tout d'abord mettre en œuvre de nouvelles idées sur la façon d'aborder la solution des problèmes que l'ancien produit résolvait.

Sommes-nous assez présomptueux pour penser que les idées de 2003 sont toujours les meilleures idées de 2011? Oui, j'ai été accusé d'arrogance, mais toute la vapeur est sortie en 2008.

Ainsi, ils ont présenté Basecamp 2 comme un produit complètement nouveau, sans aucune garantie de compatibilité ascendante avec Basecamp Classic. Beaucoup de nouvelles choses sont apparues, quelque chose a complètement disparu et beaucoup de choses ont complètement changé.

Cette décision a donné un certain degré de liberté. La liberté motive et les gens motivés travaillent mieux.

L'absence de la nécessité de prendre en charge chacune des options d'utilisation du produit d'origine a aidé. Par exemple, le camp de base d'origine vous permettait d'héberger des documents sur votre propre serveur FTP. Les développeurs ont supprimé cette fonction et d'autres fonctions similaires qui avaient du sens, mais sont maintenant marginalisées. Une telle réduction des fonctionnalités inutiles a permis de mettre un nouveau produit sur le marché dans un délai raisonnable.

Le coucher de soleil est considéré comme nocif

Mais qu'en est-il des centaines de milliers d'utilisateurs existants qui se sont fait enlever leur jouet préféré? Cela nous amène à la deuxième chose intéressante que les développeurs ont faite: ils ont conservé l'ancien produit .

David a eu un excellent tour sur le terme "logiciel Sunset":

Quelqu'un quelque part est venu avec un bel euphémisme appelé "coucher de soleil" ... Appelez la destruction du logiciel "coucher de soleil" ... Comme, tous les utilisateurs sont sur la plage - et ils regardent avec émotion comment leurs informations disparaissent. C'est super!

Les seules personnes qui croient au «coucher du soleil» sont celles qui l'appellent ainsi. Pas un seul utilisateur qui ait vraiment traversé la période du coucher du soleil ne revient et dit: "Oh, c'était magnifique." Ils reviennent et disent: «Merde! Je mets des années de travail ici! .. Et maintenant tu vas me rouler?! ”

Il a noté que forcer les gens à emballer et à déplacer est la «pire erreur stratégique» parce que vous forcez tous les clients réguliers à prendre une décision, à continuer à utiliser votre logiciel ou à passer à autre chose.

Ai-je vraiment besoin de Basecamp? Si vous devez encore transférer toutes les ordures, transférez-les peut-être ailleurs. Si vous devez emballer des choses dans des boîtes et les charger dans un camion, je peux simplement expédier ce camion à travers la ville. Pas un gros problème. Le gros problème est d'emballer tout le manat. Et où déménager, encore une fois à Basecamp ou dans un autre endroit, c'est un problème secondaire.

David a comparé le Basecamp Classic au Leica M3: l'appareil photo n'est plus produit depuis 1967, mais Leica promet de l'entretenir et de le réparer jusqu'à la fin de ses jours (photo: Dnalor 01 )

Au lieu de cela, Basecamp s'est engagé à «respecter son héritage» : ils ont simplifié la mise à niveau vers la nouvelle version, mais n'ont pas exigé de quitter Basecamp Classic. En outre, ils se sont engagés à maintenir Basecamp Classic pour toujours.

La blague, c'est qu'après quatre ans, ils l'ont fait à nouveau: en 2015, Basecamp 3 est sorti, à nouveau réécrit à partir de zéro, avec de nouvelles fonctionnalités et sans anciennes, et encore une fois, beaucoup de choses ont changé. Comme précédemment, les utilisateurs de versions plus anciennes peuvent facilement mettre à niveau. Mais s'ils le souhaitent, ils peuvent continuer à utiliser Basecamp Classic ou Basecamp 2 "jusqu'à la fin d'Internet".

Basecamp 3 ne va rien rouler. Pas la version actuelle, pas la version classique et originale de Basecamp. Est-ce que certains de ces éléments fonctionnent bien pour vous? Cool! Merci de continuer à l'utiliser jusqu'à la fin d'Internet! Nous nous assurons que les programmes restent rapides, sûrs et toujours accessibles.

Mais il y a beaucoup de "mais". N'est-ce pas cher? Le support multi-versions demande-t-il beaucoup d'efforts? Et la sécurité? Qu'en est-il des bases de code obsolètes? Que puis-je dire. Nous nous soucions juste des clients, même s'ils ne veulent pas être mis à jour selon notre calendrier.

Conclusions

Personnellement, ce modèle me semble vraiment inspirant.

Chaque modification a permis à Basecamp de regarder en arrière et de refaire le produit en fonction de l'expérience. Pour les utilisateurs, c'est un jeu gagnant-gagnant: les conservateurs gardent leur jouet; et les innovateurs confrontés aux limites du système obtiennent une application nouvelle et, je l'espère, plus réfléchie.

Bien sûr, la prise en charge de plusieurs versions pendant une durée infiniment longue a un prix; mais comme le dit David:

Ce n'est pas gratuit. Bien sûr que non. Il s'agit d'un produit précieux et bien sûr, le support n'est pas gratuit. Mais ça vaut le coup.

---

3. Visual Studio et VS Code

Remarque: icône Hipster

Microsoft a créé VS Code pour atteindre les développeurs sur d'autres plates-formes.

Vous devez vous rappeler que depuis longtemps, Microsoft propose «tout ou rien». Si vous avez utilisé Visual Studio, vous devez avoir travaillé dans .NET et vice versa. Cela a divisé la communauté des logiciels en deux grands camps, pour la plupart mutuellement exclusifs - au détriment de tous.

Appel aux gars sympas

La situation a commencé à changer dans les années de Steve Ballmer: rappelez-vous à quel point la décision des développeurs ASP.NET de ne pas inventer jQuery est devenue forte!

L'une des principales tâches du PDG de Satya Nadella était de contacter les développeurs à l'extérieur de son "jardin clôturé".

Mais il y avait un problème. Voici ce que Julia Lewson, vice-présidente de Visual Studio dans cette édition du podcast The Changelog, dit :

Nous ne pouvions pas offrir toute une classe de développeurs: modernes, orientés Web, qui travaillent avec Node et JavaScript - nous n'avions tout simplement rien à discuter avec eux. Nous ne pouvions tout simplement pas attirer ces développeurs.

Donc, le VS Code a été créé pour briser cette barrière et dire: «Vraiment quoi, les gars? Nous avons encore quelque chose d'utile pour vous. »

Visual Studio est un produit lourd dans tous les sens: seule l'installation peut prendre plus d'une demi-heure. Il prend en charge un large éventail de cas d'utilisation complexes sur lesquels les entreprises clientes comptent. Il était donc inutile de prendre Visual Studio comme point de départ et d' ajouter des fonctionnalités dans un nouveau projet sur d'autres plates-formes. Et évidemment, l'idée de publier Visual Studio pour Mac ou Linux n'était pas particulièrement prise en charge.

Par conséquent, Microsoft est parti de zéro, sans garantie de compatibilité descendante.

En fait, pas tout à fait à partir de zéro: Microsoft avait déjà quelques parties importantes, comme l'éditeur Monaco dans le navigateur. Et puisque VS Code est une application Node.js (écrite en Typescript et lancée dans Electron), ils ont profité des riches ressources de l'écosystème JavaScript.

Open Source VS Code, léger, rapide, extensible - ce qui est surprenant pour un produit Microsoft - est devenu un outil de programmation tendance pour les jeunes avancés.


VS Code est devenu le principal éditeur de JS-hipsters (diagramme du rapport State of JavaScript Survey, 2018 )

Les deux produits sont toujours en cours de développement actif et rien n'indique que Microsoft a l'intention de fermer Visual Studio.

Conclusions

Netscape, Microsoft VS Code open source . .


, Visual Studio Code 13- GitHub — , Linux!

, . open source , Microsoft Netscape — , Microsoft , .

: Microsoft VS Code , 10 000 .

L'une des dernières conclusions de l'histoire de VS Code est qu'au cours des dernières années, tout a radicalement changé: de nos jours, il est plus facile que jamais de créer des prototypes et des logiciels .

Malgré les gémissements sur la complexité des outils modernes , l'écosystème JavaScript au cours des dernières années est devenu un véritable paradis pour les modules open source. À cet égard, c'est maintenant une période sans précédent.

---

4. Gmail et boîte de réception

:

Inbox for Gmail UX Gmail, « , ». Gmail, : (bundles), .

, , Inbox. , Inbox — , Gmail, Gmail, , Inbox.

,

Inbox Gmail . , , . : Inbox (, ), Gmail , .

Inbox — , Google . , Google Inbox .



, . Gmail, , Inbox : , , . Gmail Inbox.

Inbox Gmail: , « » (snoozing), .

Conclusions

Inbox a permis aux développeurs Gmail de tester des fonctionnalités sans perturber le flux de travail de la grande majorité des utilisateurs.

Cependant, desservant les deux versions sur le même backend , Gmail a imposé de sévères restrictions à l'innovation .

Encore une fois, Google a été beaucoup critiqué pour avoir fermé le service populaire. Bien sûr, Google ferme constamment ses projets , donc rien d'inattendu.

Mais dans ce cas, l'attitude initiale de Google envers Inbox nous a amenés à croire que nous avons une démo de l'avenir de Gmail. Comme dirait DHH, le coucher du soleil s'est révélé laid: beaucoup de gens ont trouvé désagréable de revenir à un ancien produit et de perdre les flux de travail innovants d'Inbox.

Je pense que pour beaucoup, la transition aurait été beaucoup plus facile si, avant de fermer Inbox, toutes ses fonctions avaient été intégrées dans Gmail.

---

5. FogBugz & Trello

: «, , »

FogBugz — , : , « » .

Jira GitHub Issues - FogBugz. 2000 , Fog Creek Software, . FogBugz . , SaaS .

FogBugz , , . , .

FogBugz ASP, Windows. ASP.NET, , .

FogBugz Linux, Thistle ASP PHP. 2006 Thistle Wasabi, ASP, PHP JavaScript.

Wasabi

, — , , . , .

- Wasabi . , , , . - :

— . , , , .

Joel a insisté sur le fait que la décision était logique d'un point de vue commercial. Bien sûr, théoriquement, cela ne vaut pas la peine d'inventer votre propre langage, mais si vous évaluez chaque petit pas vers une telle décision, compte tenu du contexte technologique et de la base de code, alors tout semblait logique.

Réfléchissant sur Wasabi dans un essai substantiel intitulé «La dette technique et la recherche du vent», l' ancien ingénieur de Fog Creek, Ted Unangst, compare le processus à un voyage sans carte:

Imaginez que vous êtes à Savannah, en Géorgie, et que vous souhaitez aller à Londres, en Angleterre. Vous n'avez pas de carte, seulement un vague sens de l'orientation ... Vous n'allez pas en ligne droite car vous n'avez pas de bateau, mais l'océan devant vous. Mais d'un autre côté, une plage agréable mène au nord-est, et c'est approximativement la bonne direction. Vous marchez le long de la plage, marchez et marchez. Le temps passe. Vous regardez et voyez qu’à chaque étape, il se rapproche de l’objectif, bien que vous ne vous y dirigiez pas directement.

Quelque part à Boston ou en Nouvelle-Écosse, vous vous arrêtez enfin pour réfléchir à votre choix. Peut-être que cette route ne mène pas à Londres? Loin de la galerie, vous pouvez entendre des rires: «Ha ha ha, regardez ces crétins. Ils ne voient pas la différence entre l'Angleterre et la Nouvelle-Angleterre. Donnez à ces imbéciles une carte. " Mais c'est précisément le problème: vous n'avez pas de carte. Les cartes sont faites par des gens qui, par définition, ne savent pas où ils vont.

Dans tous les cas, explique Jacob Krall, un autre ancien développeur de Fog Creek, la solution a sacrifié la maintenabilité de demain pour la vitesse de développement d'aujourd'hui. Et en 2010, les comptes de cette dette ont commencé à arriver.

Nous n'avons pas mis [Wasabi] en open source, nous avons donc engagé les coûts seuls, en raison de nos principaux produits rentables ... C'était une énorme dépendance qui nécessitait un développeur permanent sur ce seul produit: pas bon marché pour une entreprise de notre taille. Parfois, le compilateur maudissait un morceau de code qui semblait tout à fait raisonnable pour une personne. Il compila lentement. Visual Studio ne pouvait pas facilement éditer ou connecter le débogueur à FogBugz ... Tous les nouveaux employés ont d'abord été formés pendant longtemps par Wasabi, quelle que soit leur expérience précédente ... De plus, nous ne vivions pas dans le vide. Les langages de programmation, bien sûr, se sont améliorés en dehors de Fog Creek ... Les développeurs ont commencé à sentir que leurs idées brillantes sont confrontées aux limites de notre petit univers Wasabi.

Point d'inflexion

À ce moment-là, FogBugz avait déjà dix ans: c'était un produit mature et stable. En parallèle, Joel a lancé Stack Overflow avec Jeff Atwood (évidemment, la tête soufflée de Jeff avait réussi à guérir à ce moment-là).

FogBugz vieillit progressivement. Bien que le marché du traqueur de bogues soit resté fragmenté, la Jira d'Atlassian, qui est sortie quelques années après FogBugz, est apparue au premier plan. C'est devenu le choix par défaut, en particulier pour les grandes entreprises.

Il est vraiment intéressant de regarder ce point d'inflexion particulier dans l'histoire de FogBugz. Comme Basecamp, ils avaient un produit rentable et mature. Oui, ce n’est plus si à la mode et ce n’était peut-être pas très intéressant de travailler dessus. Pour le meilleur ou pour le pire, il intègre de nombreuses années de changements technologiques et de nouvelles idées sur la façon de résoudre un problème spécifique: le suivi des bogues.

Bien sûr, il y avait une option Basecamp: en tenant compte de toute l'expérience, prenez et réécrivez FogBugz à partir de zéro. Je suppose que cette idée n'est pas allée trop loin, car nous nous souvenons: «ce qui ne peut jamais être fait», «la pire erreur stratégique» et ainsi de suite.

J'ai récemment attiré l'attention d'un article de 2009 que Joel a écrit pour Inc. Magazine La chronique de son auteur intitulée "Est-ce qu'une croissance lente signifie une mort lente?" son ton est complètement différent de la pompe de confiance en soi ordinaire: il sonne introspectivement, incertain, rempli de doutes. Joel s'inquiète de la croissance rapide d'Atlassian et se demande s'il y a de la place pour plusieurs acteurs sur le marché.

Je devais réfléchir. Nous avons un gros concurrent qui croît beaucoup plus vite que nous. La société conclut de gros contrats avec de grandes entreprises clientes ... Pendant ce temps, notre produit est bien meilleur et nous sommes une entreprise bien gérée, mais cela ne semble pas avoir d'importance. Pourquoi?

Il décide de faire deux choses. Tout d'abord, ajoutez toutes les fonctionnalités de FogBugz :

La tâche de l'équipe de développement pour 2010 est d'éliminer toute raison possible pour laquelle les clients peuvent acheter des ordures à nos concurrents simplement parce qu'il existe une petite fonction dont ils ne peuvent absolument pas se passer. Honnêtement, je ne pense pas que ce sera très difficile.

Deuxièmement, créez une équipe de vente d'entreprise . Joel admet qu'il n'est pas fort ici et trouve cette tâche désagréable.

Je ne sais pas comment ces mesures ont fonctionné. Joel a mentionné FogBugz pour la dernière fois sur son blog en mai 2010 , annonçant brièvement une nouvelle version.

Un nouvel espoir

Et c'est ce qui s'est passé:

Dans le cadre du dixième anniversaire de Fog Creek Software, j'ai commencé à penser: afin de garder nos employés motivés pendant encore dix ans, nous devons commencer à travailler sur quelque chose de nouveau.

Par conséquent, ils ont été divisés en deux équipes, chacune ayant réalisé un prototype de nouveau produit. L'idée gagnante a été créée dans l'esprit d'un tableau kanban - un véritable tableau hors ligne qui est souvent utilisé dans les projets de développement logiciel: il ressemble généralement à des notes disposées en colonnes sur un tableau.

Joel a présenté ce programme comme un outil de gestion à un niveau supérieur à FogBugz:

Honnêtement, avec tout ce logiciel sophistiqué de «gestion de projet», je n'ai jamais pu suivre correctement qui travaille sur quoi ... En tant que fondateur de deux sociétés, j'ai parcouru les couloirs et vu des dizaines de personnes payées pour s'asseoir devant un ordinateur ... et je ne savais pas s'ils faisaient leur travail correctement ou s'ils jugeaient important ce qui ne comptait pas vraiment.

Lors de la création de Trello, les développeurs de Fog Creek ont ​​eu la chance d'utiliser des technologies modernes:

Nous utilisons une technologie de pointe, ce n'est donc pas sans sacrifices. Nos blessures de développeur sont dispersées dans MongoDB, WebSockets, CoffeeScript et Node. Mais maintenant, ils sont intéressés. Dans le marché du travail animé d'aujourd'hui, les programmeurs talentueux décident beaucoup de ce sur quoi ils veulent travailler. Si vous leur donnez un produit intéressant ... ils l'aimeront et ils adoreront leur entreprise.

Trello a pris en charge les plugins dès le début, alors les développeurs tiers ont commencé à aider:

Les plugins et les API ont la plus haute priorité ... Ne fabriquez jamais un produit vous-même si vous pouvez fournir une API de base, et des utilisateurs précieux ... le feront pour vous. L'équipe Trello a pour règle que si une fonction peut être implémentée via un plug-in, elle doit être implémentée de cette manière.

Les programmeurs, bien sûr, ont immédiatement compris les avantages de Trello, mais il n'y avait rien de spécifique dans l'outil pour le développement de logiciels spécifiques. Joel a décrit Trello comme un outil utile pour «tout ce dont vous voulez partager des listes avec d'autres personnes». Bientôt, Trello a commencé à être utilisé pour organiser tout de suite: des dîners hebdomadaires aux mariages et aux refuges pour chiens .

Alors que FogBugz était un produit vertical - orienté vers une niche de marché spécifique - Trello était un produit horizontal adapté à tout. Joel considère que le «mouvement horizontal» de Fog Creek est correct à ce stade:

Il est presque impossible de créer un grand produit horizontal, utile dans tous les domaines. Cela ne peut pas être coûteux, car vous êtes en concurrence avec d'autres produits horizontaux qui peuvent absorber vos coûts de développement pour un grand nombre d'utilisateurs. Il s'agit d'un risque élevé et d'une récompense élevée: cette voie n'est pas adaptée à une jeune startup, mais une bonne idée pour un deuxième ou un troisième produit d'une entreprise mature et stable telle que Fog Creek.

Pour évoluer rapidement vers un très grand nombre d'utilisateurs, Trello était initialement proposé gratuitement. Plus tard, a présenté un plan d'affaires .

En 2014, Trello a été désignée comme une entreprise indépendante. Trois ans plus tard, il a vendu plus de 425 millions de dollars avec plus de 17 millions d'utilisateurs. Ironiquement, l'acheteur était Atlassian, le vieil ennemi juré de Fog Creek.

En attendant, rentrer chez moi ...

Fog Creek a continué de développer un autre nouveau produit, un environnement de programmation collaborative appelé HyperDev , qui a ensuite été renommé GoMix puis Glitch .

Dans le même temps, le système FogBugz s'est figé dans l'obscurité. En 2017, quelqu'un a décidé que FogBugz était un nom idiot, et l'effort d'ingénierie a consisté à renommer le produit en tant que manuscrit . Un an plus tard - il y a quelques mois à peine - Fog Creek a vendu le produit à une petite entreprise DevFactory , qui a immédiatement rendu le nom de FogBugz .

Sous la direction du PDG Anil Dash, Fog Creek est devenue une entreprise mono-produit et a changé son nom pour Glitch .

Conclusions

J'ai beaucoup de réflexions à ce sujet.

La clé pour comprendre l'histoire est que Fog Creek ne s'est toujours pas autant soucié du suivi des bogues que de l' autonomisation des programmeurs - à commencer par le sien:

La tâche principale: créer des conditions de travail confortables. Nous avons fait des comptes personnels pour les employés, ils ne volaient qu'en première classe, travaillaient 40 heures par semaine, recevaient un déjeuner gratuit, des chaises Aeron et les meilleurs ordinateurs. Nous avons partagé notre formule ingénieuse avec le monde: excellentes conditions de travail → excellents programmeurs → excellents logiciels → profit!

Sur la base de cette «formule», une conclusion logique et encourageante peut être tirée: Fog Creek a bâti une entreprise autour du bonheur des développeurs. Cela a affecté à la fois les produits de l'entreprise et son «système d'exploitation» interne. Le premier produit, un traqueur de bogues, a servi de base au lancement d'un nouveau produit qui a résolu un problème similaire de manière plus abstraite.

Selon Joel, il semble que l'histoire de Trello ne soit pas tant une recherche d'une nouvelle entreprise que des opportunités pour soutenir la motivation et l'implication des développeurs de Fog Creek . Un produit d'un demi-milliard de dollars n'était qu'un effet secondaire agréable.

Cependant, un peu triste de voir comment tout cela s'est terminé pour FogBugz. Je ne pense pas que les développeurs de Fog Creek étaient particulièrement heureux dans les derniers jours avant la vente.

Il est clair qu'il y avait des projets plus importants et plus importants: Stack Overflow, Trello et Glitch - chacun individuellement est beaucoup plus utile et plus précieux que FogBugz; et il est impossible pour une seule personne de tout suivre. Par conséquent, je ne peux blâmer personne, en particulier, pour la perte d'intérêt pour FogBugz avec une base de code de 20 ans et une forte concurrence sur le marché. Mais les utilisateurs fidèles ont au moins trouvé une bonne maison et n'ont pas reçu de médicament au coucher du soleil!

Cependant, la partie sentimentale de moi préférerait plus honorablement «honorer l'héritage» de tous ceux qui ont participé à la création et à l'utilisation de ce produit au cours des dernières années.

---

6. FreshBooks et BillSpring

Remarque: icône d'opération secrète

L'article a augmenté plus que ce à quoi je m'attendais, mais je ne peux pas laisser cette histoire de côté. Attendez, il y aura un virage inattendu.

Arrête-moi si tu l'as déjà entendu

Au début des années 2000, Mike McDerment avait une petite entreprise de design. Il a décidé que le logiciel de comptabilité était trop compliqué, il a donc utilisé Word et Excel pour la facturation.

Tout a bien fonctionné jusqu'à un cas :

Le moment critique est venu où seul le boîtier a enregistré une facture client importante - je viens de cliquer sur le bouton souhaité. Je savais qu'il devait y avoir un meilleur moyen, alors j'ai passé les deux prochaines semaines à programmer un prototype qui serait le fondement des FreshBooks d'aujourd'hui.

Mike est un designer, pas un programmeur, mais lui et les deux co-fondateurs ont réussi à mettre en place un outil suffisamment bon pour que plusieurs personnes paient 10 $ par mois pour l'utiliser. Il a fallu près de quatre ans à l'entreprise pour quitter le sous-sol du domicile parental.

Au 10e anniversaire du programme (cela vous semble familier?), Freshbooks est devenu une entreprise rentable avec plus de 10 millions d'utilisateurs et 300 employés.

Mais il y avait un problème. Au moment où l'entreprise a réussi à embaucher de «vrais» programmeurs, ils avaient un million de lignes de «code fondateur». Un analyste externe a examiné la base de code et a conclu:

«La bonne nouvelle est que vous avez résolu la tâche la plus difficile. Vous avez compris comment créer une entreprise et vous avez un produit que les gens aiment. La mauvaise nouvelle, c'est que vous êtes peu familiarisés avec la technologie . »

Plus important encore, il était impossible de mettre en œuvre les idées existantes dans un produit existant:

Nous avons fondé l'entreprise il y a plus de dix ans, le monde a changé et nous avons beaucoup appris sur le développement de programmes et les besoins des entrepreneurs individuels, qui deviennent de plus en plus dans la société ... nous savions que des efforts devaient être faits pour maintenir FreshBooks à jour dans cinq ans.

MacDerment est familier avec la sagesse conventionnelle selon laquelle vous ne pouvez pas réécrire un système à partir de zéro:

La réécriture de code à partir de zéro est le plus grand risque pour une entreprise de logiciels. Très probablement, vous ne terminerez même pas le projet. Cela prendra plus de temps que prévu et coûtera plus cher. Le résultat final peut ne pas plaire aux clients. Et rien ne garantit que la nouvelle plateforme sera réellement meilleure que la précédente. La règle numéro un dans le logiciel n'est pas de réécrire votre logiciel.

Ainsi, ils ont fait plusieurs tentatives pour effacer le gâchis sans réécrire le système à partir de zéro; mais «remplacer les pneus sur le pouce» n'était pas possible.

Ce qui s'est passé ensuite peut vous surprendre

McDermint a été visité par l'idée de créer secrètement un "concurrent" FreshBooks.

Il a fondé une toute nouvelle entreprise au Delaware appelée BillSpring. Elle avait son propre site Web, sa propre marque et son propre logo. Essayant de ne pas connecter les deux sociétés, il a chargé un avocat externe de développer de nouveaux documents pour elle.

L'équipe de développement a mis en œuvre des pratiques de développement flexibles basées sur le livre de Jeff Gottelf et Josh Seiden «Lean UX: concevoir de grands produits avec des équipes flexibles» : des équipes Scrum et des itérations hebdomadaires avec des commentaires de vrais clients. MacDerment leur a demandé d'agir comme une startup et de le prendre comme un investisseur en capital-risque:

«Vous avez quatre mois et demi. Si vous entrez sur le marché, gagnez plus d'argent. Sinon, la fin. "

L'équipe a réussi à libérer MVP quelques jours avant la date limite. Ils ont acheté des mots clés AdWords pour générer du trafic et ont offert aux utilisateurs des comptes gratuits pour la première année. Bientôt, des clients sont apparus - et des cycles d'itération rapides du vrai produit ont commencé.

À la fin de la première année, BillSpring a commencé à facturer. À un moment donné, le nouveau produit a reçu une évaluation inattendue de la qualité :

«Une personne a appelé pour se désinscrire de FreshBooks et se rendre dans notre nouvelle entreprise», explique McDermint. "C'était une super journée."

Bientôt, ils ont levé le voile du secret et ont informé les clients de BillSpring qu'il s'agissait d'un produit FreshBooks, et ils ont également informé les clients FreshBooks existants qu'une nouvelle version allait bientôt arriver.

Peu à peu, les clients des «classiques» FreshBooks ont été admis à la nouvelle version, mais ils pouvaient toujours revenir à l'ancienne s'ils le voulaient.

Conclusions

Le projet secret FreshBooks n'était pas bon marché: selon McDermint, ils y ont dépensé 7 millions de dollars. Cependant, après plus d'une décennie de croissance, ils ont levé 30 millions de dollars en capital-risque uniquement sur leurs propres ressources, donc il y avait de l'argent. Tout le monde ne peut pas se le permettre.

Forbes a estimé les revenus de FreshBooks à 20 millions de dollars en 2013. Une fois la mise à jour terminée en 2017, ils ont gagné 50 millions de dollars. On ne sait pas combien provenait du nouveau produit, mais l'écriture d'un système à partir de zéro n'a clairement pas ralenti la croissance de l'entreprise.

MacDerment dit que le processus de développement et de mise en œuvre de nouvelles fonctionnalités est devenu plus rapide et plus facile. Plus important encore, ils ont maintenant un produit entre les mains qui met en œuvre les meilleures idées. Avec cela, on n'a pas peur de regarder vers l'avenir.

De plus, l'expérience acquise a changé la culture de l'entreprise - dans le bon sens. Quand ils ont fait semblant d'être une startup, ils ont appris à travailler en tant que startup. Les pratiques Lean UX se sont étendues à toute l'équipe de développement. Les clients participent activement au développement de nouvelles fonctionnalités.

FreshBooks a pris des mesures extraordinaires pour se protéger des problèmes potentiels: en introduisant des innovations sous une fausse marque, les développeurs pourraient repenser complètement le programme et prendre de gros risques. Même dans le pire des cas, ils ne nuiront pas à la marque existante.

Tout cela semble un peu extrême. Peut-être que de telles mesures n'étaient pas nécessaires. Mais c'est un rappel de la gravité des enjeux.

---

Quelques réflexions

Il est généralement admis qu'il vaut mieux éviter de réécrire le programme à partir de zéro et apporter des améliorations graduelles si possible. Pour la plupart, je suis d'accord avec cela.

Mais les conseils suggèrent qu'au final, nous obtenons un produit original et un ensemble de nouvelles fonctionnalités.

Mais que faire si vous souhaitez supprimer des fonctionnalités? Ou implémenter une option complètement différemment ? Et si l'expérience venait avec les idées d'une approche complètement nouvelle?

Ma conclusion de ces histoires est la suivante: dès que vous comprenez que la version actuelle est très différente de l'idéal imaginaire , la nouvelle version ne devrait pas être publiée en remplacement, mais en parallèle avec la version actuelle .

Lorsqu'il y a des idées pour tout réécrire à partir de zéro, il peut être utile de poser d'autres questions. Peut-être créer votre propre concurrent? Si mon produit est FogBugz, alors quel sera mon Trello? S'il s'agit de Visual Studio, à quoi ressemblera mon code VS?

Si nous comparons l' article de Spolsky sur Netscape et le post DHH sur Basecamp, ils s'accordent sur une chose: Legacy a de la valeur.

La bonne nouvelle est que vous n’avez pas besoin de jeter cette valeur pour innover.