Seis historias de cómo se reescribió el código desde cero

Una nueva mirada a la antigua pregunta: ¬Ņdeber√≠a reescribirse la aplicaci√≥n desde cero o es "el peor error estrat√©gico que puede cometer un desarrollador de software"? Resulta que cuando se trabaja con una base de c√≥digo madura hay m√°s de dos opciones de respuesta.



"¡El código fuente parece estar oxidado !" - Joel Spolsky

Hace casi dos décadas, Joel Spolsky organizó a Netscape por reescribir la base de código del navegador en su ensayo épico "Lo que nunca puedes hacer" . Llegó a la conclusión de que el software en funcionamiento nunca debe reescribirse desde cero . Tenía dos argumentos principales:

  • Las partes de la base del c√≥digo que parecen basura a menudo incluyen conocimientos adquiridos con esfuerzo sobre situaciones fronterizas y errores extra√Īos.
  • La alteraci√≥n completa es una empresa a largo plazo que distrae de mejorar el producto existente, lo que da cartas de triunfo a los competidores.

Para muchos, los hallazgos de Joel se han convertido en dogma; En un momento tuvieron una gran influencia en m√≠. Pero en los a√Īos siguientes, me di cuenta de que, en algunas circunstancias, todav√≠a tiene sentido rehacer completamente el producto. Por ejemplo:

  • A veces, una base de c√≥digo desactualizada realmente no es recuperable, por lo que incluso una simple actualizaci√≥n requiere cambios en cascada en otras partes del c√≥digo.
  • Las soluciones tecnol√≥gicas originales pueden interferir con las mejoras necesarias.
  • O bien, la tecnolog√≠a original puede estar desactualizada, lo que hace que sea dif√≠cil (o demasiado costoso) contratar desarrolladores calificados.

Por supuesto, de hecho, mucho depende de las circunstancias. Sí, a veces tiene sentido refactorizar gradualmente el código obsoleto. Y sí, a veces tiene sentido tirar todo y volver a empezar.

Pero esta no es la √ļnica opci√≥n . Echemos un vistazo a seis historias y veamos qu√© lecciones se pueden aprender.





1. Netscape



El código del navegador se reescribió tres veces desde cero

La catastrófica transición de Netscape de 5.0 a 6.0 fue la ocasión para el artículo antes mencionado de Joel Spolsky y muchos convencidos de que esto nunca debería hacerse.

Netscape Navigator se lanz√≥ en 1994, en los primeros a√Īos de la Internet comercial. Dos a√Īos despu√©s, la compa√Ī√≠a abri√≥ la era de las puntocom con una OPV de $ 3 mil millones.

El primer gran competidor de Netscape fue Microsoft Internet Explorer, lanzado en 1996.

A principios de 1998, Netscape seguía siendo el navegador líder, pero con gran dificultad. Netscape fue un programa comercial que se vendió por $ 49, y Microsoft entregó IE gratis y se entregó como el navegador predeterminado en Windows.



Con el lanzamiento de Netscape 4.0, la compa√Ī√≠a anunci√≥ que la pr√≥xima versi√≥n ser√° gratuita y ser√° desarrollada por la comunidad de c√≥digo abierto, creada y financiada por Mozilla. Para su tiempo, este fue esencialmente un movimiento sin precedentes, y Netscape gan√≥ muchos partidarios para una decisi√≥n tan audaz. Pero en realidad, esta "comunidad" en realidad no se materializ√≥. Jamie Zawinski, uno de los primeros desarrolladores de navegadores, explica :

La verdad es que el proyecto Mozilla involucró a un centenar de desarrolladores de Netscape a tiempo completo y una treintena de desarrolladores independientes, por lo que el proyecto todavía era propiedad exclusiva de Netscape.

El equipo lleg√≥ a la conclusi√≥n de que los desarrolladores externos no estaban interesados ‚Äč‚Äčen el proyecto, incluso debido al desorden en la base del c√≥digo:

El código resultó ser demasiado complicado y confuso para cambiar, por lo que la gente no contribuyó ... Es por eso que cambiamos a un nuevo motor. Una base de código más limpia y fresca que es más fácil de entender y unirse al desarrollo.

Desde cero


Por lo tanto, un a√Īo despu√©s, el grupo decidi√≥ abandonar 5.0 sin lanzar una versi√≥n, y comenz√≥ a desarrollar la versi√≥n 6.0 desde cero.

La preparaci√≥n de Netscape 6.0 tom√≥ dos a√Īos enteros; e incluso despu√©s de todo esto, estaba claro que el navegador estaba en bruto. Seg√ļn el columnista del New York Times David Pog, el navegador funcion√≥ durante un minuto completo (!) Y consumi√≥ RAM. Carece de una serie de caracter√≠sticas de usabilidad simples que estaban en versiones anteriores:

La funci√≥n de vista previa de impresi√≥n ha desaparecido, as√≠ como la capacidad de arrastrar el icono de direcci√≥n del sitio directamente al men√ļ de marcadores. Adem√°s, no puede copiar o pegar una direcci√≥n web en la barra de direcciones haciendo clic derecho sobre ella. Y cada vez que al comienzo del trabajo tiene que cambiar el tama√Īo de la ventana: Navigator no recuerda el estado anterior. Pero el inconveniente m√°s desagradable es que no puede seleccionar la barra de direcciones completa con un solo clic.

Pero eso fue casi irrelevante, porque en los tres a√Īos que Netscape se detuvo, Internet Explorer captur√≥ la cuota de mercado restante:


Cuando comenz√≥ el refinamiento del navegador, Netscape perdi√≥ terreno r√°pidamente ante Microsoft Internet Explorer. El nuevo navegador sali√≥ tres a√Īos despu√©s, ten√≠a errores y era lento; y la cuota de mercado de Netscape, mientras tanto, cay√≥ a casi cero (gr√°fico adaptado de Wikipedia )

En 1999, cuando el redise√Īo del navegador estaba en su apogeo, AOL adquiri√≥ Netscape por $ 10 mil millones. Solo dos a√Īos despu√©s del lanzamiento de Netscape 6.0, la divisi√≥n de AOL de Netscape fue liquidada.

Mozilla, la comunidad de código abierto creada por Netscape, continuará existiendo y lanzará el navegador Firefox en 2002, otro proyecto de hoja limpia. Firefox logró devolver algunos de los usuarios que se fueron a Microsoft.

Pero Netscape, como empresa, ha muerto (Microsoft enterrar√° los restos de la propiedad intelectual de Netscape como resultado de un acuerdo de 2012 con AOL).

Despu√©s de ganar esta batalla, Microsoft se neg√≥ a invertir en tecnolog√≠a de navegador. Internet Explorer 6.0 se lanz√≥ en 2001 y no se ha actualizado durante cinco a√Īos . Algunos consideran que esto es un intento deliberado de bloquear la promoci√≥n de Internet como plataforma para aplicaciones.

Conclusiones


Algunos creen que reescribir desde cero no fue un desastre. Al final, gracias a esto, el motor Gecko y el navegador Firefox finalmente aparecieron.

Pero todos tuvimos que soportar a√Īos de estancamiento en las tecnolog√≠as web bajo el monopolio interminable y sofocante de IE6 , mientras esper√°bamos un nuevo navegador que diera vida a la industria. Y el final de la era IE6 no fue puesto por Firefox, sino por Google Chrome.

En cualquier caso, no se trata de cómo el proyecto afectó a Internet. Se trata de cuál es el resultado para la empresa. La muerte de Netscape no se puede culpar por estas razones: el tribunal acordó que Microsoft abusó intencionalmente de su monopolio. Pero, por supuesto, la decisión de reescribir todo desde cero fue un factor importante y condujo al resultado final: la destrucción de una empresa por valor de miles de millones de dólares y miles de despidos. Por lo tanto, estoy de acuerdo con Joel en que las consecuencias netas de esta decisión fueron desastrosas .





2. Campamento base




A principios de la d√©cada de 2000, el estudio de dise√Īo web con sede en Chicago llamado 37signals se hizo famoso por su blog influyente y a menudo controvertido, cofundado por los fundadores Jason Fried y DHH .

Cuando comenc√© a hacer dise√Īo web, me llamaron la atenci√≥n con una serie de art√≠culos con ejemplos de dise√Īo incorrecto y opciones sobre c√≥mo rehacerlos para sitios como Google y PayPal. El proyecto se llam√≥ 37mejor .




El redise√Īo del formulario de entrega de 37 se√Īales de FedEx (arriba) sigue siendo mejor que el dise√Īo real , casi dos d√©cadas despu√©s

La compa√Ī√≠a ten√≠a un sistema de gesti√≥n de proyectos para uso interno , que lanzaron en 2004 como un servicio SaaS llamado Basecamp .

SaaS todav√≠a era nuevo en ese momento. Las herramientas de gesti√≥n de proyectos se vendieron en cajas con etiquetas de precios de cuatro d√≠gitos y manuales pesados. Todos trabajaron en el concepto de modelar caminos cr√≠ticos y dibujaron diagramas complejos de Gantt. Basecamp se vendi√≥ por $ 50 al mes y se convirti√≥ en un soplo de aire fresco con su interfaz s√ļper simple y su enfoque en la comunicaci√≥n.

Avanzando unos a√Īos, Basecamp tiene medio mill√≥n de usuarios satisfechos, los pagos llegan cada mes, pero Jason y David comenzaron a preocuparse.

Hace unos a√Īos, David cont√≥ esta historia en una conferencia de Business of Software . Admiti√≥ que fue influenciado por Joel Spolsky y cre√≠a que reescribir el software matar√≠a a la compa√Ī√≠a. Adem√°s, hab√≠a un cierto elemento de complacencia y justicia propia en relaci√≥n con la popularidad del movimiento √°gil:

[I] estaba completamente absorto en la idea del software trascendental ... Un código infinitamente flexible. Legado infinitamente valioso. Puedes cambiar cualquier cosa, reescribir cualquier programa, cualquier código ... Si el software es difícil de cambiar, es tu culpa. Eres un mal programador, por lo que debes mejorar.

Sin embargo, despu√©s de "siete a√Īos gordos", la compa√Ī√≠a se encontr√≥ en un dilema, y ‚Äč‚Äčel problema no ten√≠a nada que ver con la deuda t√©cnica .

Esposas de oro


Todo comenzó con el hecho de que los chicos notaron una falta de entusiasmo. No solo no había suficiente motivación para trabajar en un producto estrella, sino que ellos mismos no usaban particularmente su programa.

Tenían muchas ideas sobre cómo hacer que el producto sea fundamentalmente mejor, pero cualquier cambio interrumpirá los flujos de trabajo habituales de cientos de miles de usuarios de Basecamp. El problema no estaba en la base del código complejo, sino en los usuarios.

Debido al deseo de complacer a los clientes existentes, el producto se detuvo en el desarrollo, lo que impidió atraer nuevos usuarios. Esto no amenazó directamente al negocio, pero planteó una amenaza a largo plazo. DHH comparó metafóricamente la situación con un cubo con fugas:

Puede tapar todos los agujeros, corregir todos los errores, actualizar todas las funciones de las que se quejan los clientes existentes, pero parte del agua siempre fluye. Los clientes dejan el trabajo y dejan el software, incluso si les gusta. Puede que te enga√Īes: ‚ÄúOye, el cubo est√° m√°s que medio lleno. Solo hay un peque√Īo agujero, solo una peque√Īa fuga, es completamente natural ". Pero, si la situaci√≥n persiste, el cubo estar√° completamente vac√≠o.

Parte del problema es que escucha constantemente a los clientes actuales, pero no escucha a los futuros:

Las personas que visitaron la p√°gina de Basecamp en 2011 y se negaron a comprar el producto porque ya no les conven√≠a: ¬Ņc√≥mo piensan, con qu√© frecuencia escuchamos su opini√≥n? Nunca Solo escuchamos a una amplia base de clientes existentes que realmente quer√≠an que sigui√©ramos tapando estos peque√Īos agujeros.

Los desarrolladores comenzaron a considerar un producto rentable como un par de esposas de oro:

Lo principal es asegurarse de que todos los usuarios actuales estén satisfechos. El dinero llega todos los meses, un nuevo cheque, un nuevo cheque, un nuevo cheque. Genial Pero luego comuníquese y admita: "Eso es todo, nunca volveré a cambiar mi software".



Spoiler: Basecamp fue reescrito desde cero, y result√≥ genial. Tom√≥ alrededor de un a√Īo e inmediatamente despu√©s del lanzamiento de Basecamp 2, el n√ļmero de nuevos registros se duplic√≥.

Creo que hicieron dos cosas principales.

En primer lugar, no intentaron rehacer el producto anterior , porque en primer lugar querían implementar nuevas ideas sobre cómo abordar la solución de los problemas que resolvió el producto anterior.

¬ŅSomos tan presuntuosos como para pensar que las ideas de 2003 siguen siendo las mejores ideas de 2011? S√≠, me acusaron de arrogancia, pero todo el vapor sali√≥ en 2008.

Por lo tanto, introdujeron Basecamp 2 como un producto completamente nuevo, sin ninguna garantía de compatibilidad retrocompatible con Basecamp Classic. Aparecieron muchas cosas nuevas, algo desapareció por completo y muchas cosas cambiaron por completo.

Esta decisión dio un cierto grado de libertad. La libertad motiva, y las personas motivadas trabajan mejor.

La falta de la necesidad de admitir cada una de las opciones para usar el producto original ayudó. Por ejemplo, el Basecamp original le permitía alojar documentos en su propio servidor FTP. Los desarrolladores eliminaron esta y otras funciones similares que solían tener sentido, pero ahora están marginadas. Tal reducción en la funcionalidad innecesaria hizo posible llevar un nuevo producto al mercado en un tiempo razonable.

La puesta de sol se considera da√Īina


Pero, ¬Ņqu√© pasa con cientos de miles de usuarios existentes a quienes se les quit√≥ su juguete favorito? Esto nos lleva a la segunda cosa interesante que hicieron los desarrolladores: conservaron el producto anterior .

David tuvo un gran paseo en el término "software de puesta de sol":

A alguien se le ocurrió un hermoso eufemismo llamado "puesta de sol" ... Llame a la destrucción del software "puesta de sol" ... Como todos los usuarios están en la playa, y miren con emoción que su información desaparece. ¡Esto es genial!

Las √ļnicas personas que creen en la "puesta de sol" son aquellos que lo llaman as√≠. Ni un solo usuario que realmente pas√≥ por el per√≠odo de puesta del sol regresa y dice: "Oh, eso fue hermoso". Vuelven y dicen: "¬°Maldita sea! ¬°Puse a√Īos de trabajo aqu√≠! ... ¬°¬ŅY ahora me vas a enrollar ?! ‚ÄĚ

Se√Īal√≥ que obligar a las personas a empacar y moverse es el "peor error estrat√©gico" porque obliga a todos los clientes habituales a tomar una decisi√≥n, continuar utilizando su software o cambiar a otra cosa.

¬ŅRealmente necesito Basecamp? Si a√ļn tiene que transferir toda la basura, quiz√°s transfi√©rala a otro lugar. Si necesita empacar cosas en cajas y cargarlas en un cami√≥n, simplemente puedo enviar este cami√≥n por la ciudad. No es un gran problema. El gran problema es empacar todo el manat. Y d√≥nde moverse, nuevamente a Basecamp o a otro lugar, este es un problema secundario.


David comparó el Basecamp Classic con el Leica M3: la cámara no se ha producido desde 1967, pero Leica promete mantenerla y repararla hasta el final de sus días (foto: Dnalor 01 )

En cambio, Basecamp se comprometió a "respetar su legado" : simplificaron la actualización a la nueva versión, pero no exigieron abandonar Basecamp Classic. Además, se comprometieron a mantener Basecamp Classic para siempre.

La broma es que despu√©s de cuatro a√Īos lo hicieron nuevamente: en 2015, se lanz√≥ Basecamp 3, nuevamente reescrito desde cero, con algunas caracter√≠sticas nuevas y sin algunas antiguas, y nuevamente muchas cosas han cambiado. Como antes, los usuarios de versiones anteriores pueden actualizar f√°cilmente. Pero si lo desean, pueden seguir usando Basecamp Classic o Basecamp 2 "hasta el final de Internet".

Basecamp 3 no va a rodar nada. No es la versi√≥n actual, no la versi√≥n cl√°sica y original de Basecamp. ¬ŅAlguno de estos te funciona bien? Genial! ¬°Contin√ļe us√°ndolo hasta el final de Internet! Nos aseguramos de que los programas permanezcan r√°pidos, seguros y siempre accesibles.

Pero hay mucho "pero". ¬ŅNo es caro? ¬ŅEl soporte de m√ļltiples versiones requiere mucho esfuerzo? ¬ŅQu√© hay de la seguridad? ¬ŅQu√© pasa con las bases de c√≥digo obsoletas? Que puedo decir Solo nos preocupamos por los clientes, incluso si no desean ser actualizados de acuerdo con nuestro cronograma.




Conclusiones


Personalmente, este modelo me parece realmente inspirador.

Cada modificación permitió a Basecamp mirar hacia atrás y rehacer el producto en función de la experiencia. Para los usuarios, este es un juego en el que todos ganan: los conservadores conservan su juguete; y los innovadores que enfrentan las limitaciones del sistema obtienen una aplicación nueva y, espero, más reflexiva.

Por supuesto, el soporte de m√ļltiples versiones por un tiempo infinitamente largo tiene un precio; pero como dice David:

No es gratis Por supuesto que no. Este es un producto valioso y, por supuesto, el soporte no es gratuito. Pero vale la pena.







3. Visual Studio y VS Code



Nota: icono de Hipster

Microsoft creó VS Code para llegar a los desarrolladores en otras plataformas.

Debe recordar que durante mucho tiempo, Microsoft ha ofrecido "todo o nada". Si usó Visual Studio, entonces debe haber trabajado en .NET, y viceversa. Esto dividió a la comunidad de software en dos grandes campos, en su mayoría mutuamente excluyentes, en detrimento de todos.

Apelar a los chicos geniales


La situaci√≥n comenz√≥ a cambiar en los a√Īos de Steve Ballmer: ¬°recuerden cu√°n fuerte se hizo la decisi√≥n de los desarrolladores de ASP.NET de no inventar jQuery !

Una de las principales tareas del CEO de Satya Nadella fue contactar a los desarrolladores fuera de su "jardín cercado".

Pero hubo un problema. Esto es lo que dice Julia Lewson, vicepresidenta de Visual Studio en esta edición del podcast The Changelog :

No podríamos ofrecer una clase completa de desarrolladores: modernos, orientados a la web, que trabajen con Node y JavaScript, simplemente no teníamos nada de qué hablar con ellos. Simplemente no pudimos atraer a estos desarrolladores.

Entonces, el C√≥digo VS fue creado para romper esa barrera y decir: ‚Äú¬ŅRealmente saben qu√©, muchachos? Todav√≠a tenemos algo √ļtil para ti.

Visual Studio es un producto pesado en todos los sentidos: solo la instalación puede llevar más de media hora. Admite una amplia gama de casos de uso complejos en los que confían los clientes corporativos. Por lo tanto, no tenía sentido tomar Visual Studio como punto de partida y agregar características en un nuevo proyecto en otras plataformas. Y obviamente, la idea de lanzar Visual Studio para Mac o Linux no fue particularmente compatible.

Por lo tanto, Microsoft comenzó desde cero, sin garantías de compatibilidad con versiones anteriores.

En realidad, no desde cero: Microsoft ya tenía algunas partes importantes, como el editor de Mónaco en el navegador. Y dado que VS Code es una aplicación Node.js (escrita en Typecript y lanzada en Electron), aprovecharon los ricos recursos del ecosistema JavaScript.

El código VS de código abierto, ligero, rápido y extensible, lo cual es sorprendente para un producto de Microsoft, se ha convertido en una herramienta de programación moderna para la juventud avanzada.


VS Code se convirtió en el editor principal de JS-hipsters (diagrama del informe State of JavaScript Survey, 2018 )

Ambos productos todavía están en desarrollo activo, y no hay indicios de que Microsoft tenga la intención de cerrar Visual Studio.

Conclusiones


A diferencia de Netscape, Microsoft realmente logró crear una comunidad de código abierto activa en torno a VS Code. Ha aumentado los esfuerzos de los desarrolladores para mejorar el producto.


De todos los proyectos de c√≥digo abierto, Visual Studio Code ocupa el puesto 13 en t√©rminos de n√ļmero de estrellas en GitHub, ¬°casualmente, justo debajo de Linux!

Por supuesto, no todas las empresas pueden permitir que su producto principal esté disponible gratuitamente. Pero si el código abierto es parte de su estrategia de desarrollo, tiene sentido comparar las historias de Microsoft y Netscape, y descubrir qué hizo Microsoft de manera diferente para que su comunidad florezca.

Otro factor importante: Microsoft ha proporcionado a VS Code un modelo de extensibilidad de alta calidad , como resultado de lo cual la comunidad ya ha escrito alrededor de 10,000 extensiones.

Una de las √ļltimas conclusiones de la historia de VS Code es que en los √ļltimos a√Īos, todo ha cambiado dr√°sticamente: hoy en d√≠a es m√°s f√°cil que nunca crear prototipos y software .

A pesar de los gemidos sobre la complejidad de las herramientas modernas , el ecosistema de JavaScript en los √ļltimos a√Īos se ha convertido en un verdadero para√≠so de m√≥dulos de c√≥digo abierto. En este sentido, ahora es un momento hist√≥ricamente sin precedentes.





4. Gmail y bandeja de entrada



Nota: el ícono del atardecer de

Inbox for Gmail se introdujo originalmente como un UX minimalista alternativo para Gmail, "con un enfoque en lo que realmente importa". Nunca trató de igualar la funcionalidad del Gmail original e introdujo nuevas características: grupos temáticos (paquetes), cartas ancladas y mensajes pendientes.

Algunos usuarios, incluyéndome a mí, aceptaron con entusiasmo Inbox. Siempre pensé que Inbox era una demostración de lo que eventualmente se convertiría en Gmail, así que soporté la falta de algunos de los matices de Gmail, esperando que eventualmente llegaran a Inbox.

Dos interfaces, un servicio.


Inbox y Gmail trabajaron en el mismo backend. De hecho, estas son solo interfaces de usuario diferentes para el mismo servicio, y puede cambiar de un lado a otro como lo desee. Esto ten√≠a sus ventajas y desventajas: si la Bandeja de entrada carec√≠a de una funci√≥n (por ejemplo, un contestador autom√°tico para las vacaciones), siempre pod√≠a volver a Gmail y configurar lo que necesitaba, aunque cambiar de ida y vuelta parec√≠a extra√Īo.

Sin embargo, despu√©s de un tiempo, Inbox dej√≥ de mejorar: qued√≥ claro que Google ya no estaba invirtiendo recursos en √©l. Naturalmente, cuatro a√Īos despu√©s del lanzamiento, Google anunci√≥ la puesta de sol de Inbox .



Como todos los dem√°s, al principio estaba enojado con tal decisi√≥n. Pero despu√©s de pasar un poco de tiempo con la √ļltima versi√≥n de Gmail, descubr√≠ que muchas de mis funciones favoritas de la Bandeja de entrada se han trasladado al producto original : una respuesta inteligente, acciones de desplazamiento, archivos adjuntos incorporados e im√°genes. Varios buzones de correo de Gmail reemplazan bastante bien los grupos de temas de la Bandeja de entrada.

Pero no todo desde Inbox fue transferido a Gmail: por ejemplo, la gente está tan acostumbrada al "modo de pausa" (dormitando) que sin ella literalmente sufren físicamente.

Conclusiones


Inbox permitió a los desarrolladores de Gmail experimentar con funciones sin interrumpir el flujo de trabajo de la gran mayoría de los usuarios.

Sin embargo, al servir ambas versiones en el mismo backend , Gmail ha impuesto severas restricciones a la innovación .

Una vez m√°s, Google ha sido muy criticado por cerrar el popular servicio. Por supuesto, Google cierra constantemente sus proyectos , por lo que nada inesperado.

Pero en este caso, la actitud inicial de Google hacia Inbox nos llevó a creer que tenemos una demostración del futuro de Gmail. Como diría DHH, la puesta de sol salió fea: a muchas personas les pareció desagradable volver a un producto antiguo y perder los flujos de trabajo innovadores de Inbox.

Creo que para muchos, la transición habría sido mucho más fácil si, antes de cerrar Inbox, todas sus funciones estuvieran integradas en Gmail.





5. FogBugz y Trello



Nota: La insignia de

FogBugz y las insignias de "dinero, dinero, dinero" son un caso particularmente interesante, ya que este es un producto del propio Joel Spolsky: da una idea de cómo se enfrenta el principio de "nunca reescribir" con la vida real.

Antes de la aparici√≥n de Jira y GitHub Issues, hab√≠a un sistema de seguimiento de tickets basado en la web llamado FogBugz. Lanzado en 2000, este sistema fue el primer producto de la nueva compa√Ī√≠a de software Fog Creek, que Joel fund√≥ con Michael Prior. Y durante m√°s de una d√©cada, FogBugz ha seguido siendo su producto estrella. Inicialmente, solo se vend√≠a como una versi√≥n en caja para su instalaci√≥n en sus propios servidores, pero luego se lanz√≥ una opci√≥n SaaS con pago de suscripci√≥n.

FogBugz se ha vuelto muy popular, especialmente entre los desarrolladores que, en mi ejemplo, leyeron el blog de Joel y tomaron en serio sus consejos. Mi empresa utiliz√≥ el sistema durante muchos a√Īos, fue un gran producto para su √©poca.

FogBugz se escribió originalmente en el ASP clásico, que funcionaba en servidores Windows. Cuando salió ASP.NET, Joel explicó por qué no tenía prisa por actualizar .

Para instalar FogBugz en servidores Linux, un pasante de la compa√Ī√≠a escribi√≥ un compilador Thistle para convertir ASP cl√°sico a PHP. Para 2006, Thistle se hab√≠a convertido en un lenguaje de programaci√≥n patentado llamado Wasabi, que se compilaba en ASP, PHP y JavaScript del lado del cliente.

La extra√Īa historia de wasabi


Hoy en día, desarrollar su propio lenguaje de programación propietario y compilador es, digamos, una elección excéntrica. Entonces es interesante ver cómo sucedió todo.

En un momento, Joel mencion√≥ Wasabi en una de sus publicaciones de blog. Algunos pensaron que era una broma, por lo que explic√≥ que no era una broma . Jeff Atwood, un compa√Īero bloguero, se sorprendi√≥ de esta noticia:

Escribir en su propio idioma es absolutamente más allá de los límites. Esta es una solución tóxica que está tan en desacuerdo con los excelentes y robustos consejos de desarrollo de software anteriores de Joel que la gente realmente pensó que estaba bromeando.

Joel insisti√≥ en que la decisi√≥n ten√≠a sentido desde una perspectiva comercial. Por supuesto, en teor√≠a no vale la pena inventar su propio idioma, pero si eval√ļa cada peque√Īo paso hacia esa decisi√≥n, dado el contexto tecnol√≥gico y la base del c√≥digo, entonces todo parece l√≥gico.

Reflexionando sobre Wasabi en un ensayo sustancial titulado "Deuda t√©cnica y la b√ļsqueda del viento", el ex ingeniero de Fog Creek, Ted Unangst, compara el proceso con viajar sin un mapa:

Imagina que estás en Savannah, Georgia, y quieres ir a Londres, Inglaterra. No tienes un mapa, solo un vago sentido de dirección ... No vas en línea recta, porque no tienes un bote, sino el océano frente a ti. Pero, por otro lado, una playa agradable conduce al noreste, y esta es aproximadamente la dirección correcta. Caminas por la playa, caminas y caminas. El tiempo pasa Usted mira y ve que con cada paso se está acercando a la meta, aunque no se mueve directamente hacia ella.

En alg√ļn lugar de Boston o Nueva Escocia, finalmente te detienes y piensas en tu elecci√≥n. Tal vez este camino no conduce a Londres? Lejos de la galer√≠a se puede escuchar la risa: "Ja, ja, ja, mira a estos imb√©ciles. No ven la diferencia entre Inglaterra y Nueva Inglaterra. Dale a estos tontos un mapa. Pero este es precisamente el problema: no tienes una tarjeta. Los mapas est√°n hechos por personas que casi por definici√≥n no saben a d√≥nde van.

En cualquier caso, explica Jacob Krall, otro antiguo desarrollador de Fog Creek, la soluci√≥n sacrific√≥ la mantenibilidad del ma√Īana por la velocidad de desarrollo de hoy. Y para 2010, comenzaron a llegar las cuentas de esta deuda.

No pusimos [Wasabi] en c√≥digo abierto, por lo que incurrimos en los costos solo, debido a nuestros principales productos rentables ... Era una gran dependencia que requer√≠a un desarrollador permanente solo en este producto: no es barato para una empresa de nuestro tama√Īo. A veces, el compilador maldijo un c√≥digo que parec√≠a bastante razonable para una persona. Lentamente compil√≥. Visual Studio no pudo editar o conectar f√°cilmente el depurador a FogBugz ... Todos los nuevos empleados fueron capacitados por Wasabi por mucho tiempo, independientemente de su experiencia previa ... Adem√°s, no viv√≠amos en el vac√≠o. Los lenguajes de programaci√≥n, por supuesto, han mejorado fuera de Fog Creek ... Los desarrolladores han comenzado a sentir que sus brillantes ideas se enfrentan a las limitaciones de nuestro peque√Īo universo Wasabi.

Punto de inflexión


Para entonces, FogBugz ya ten√≠a diez a√Īos: era un producto maduro y estable. Como proyecto paralelo, Joel lanz√≥ Stack Overflow junto con Jeff Atwood (obviamente, la cabeza rota de Jeff hab√≠a logrado sanar para entonces).

FogBugz est√° envejeciendo gradualmente. Aunque el mercado de rastreadores de errores segu√≠a fragmentado, Jira de Atlassian, que sali√≥ un par de a√Īos despu√©s de FogBugz, se destac√≥. Se ha convertido en la opci√≥n predeterminada, especialmente para los grandes usuarios corporativos.

Es realmente interesante observar este punto de inflexi√≥n en particular en la historia de FogBugz. Al igual que Basecamp, ten√≠an un producto rentable y maduro. S√≠, ya no est√° tan de moda y tal vez no fue muy interesante trabajar en ello. Para bien o para mal, incorpora muchos a√Īos de cambios tecnol√≥gicos y nuevas ideas sobre c√≥mo resolver un problema espec√≠fico: el seguimiento de errores.

Por supuesto, había una opción de Basecamp: teniendo en cuenta toda la experiencia, tomar y reescribir FogBugz desde cero. Supongo que esta idea no fue demasiado lejos, porque recordamos: "lo que nunca se puede hacer", "el peor error estratégico" y así sucesivamente.

Hace poco me llam√≥ la atenci√≥n un art√≠culo de 2009 que Joel escribi√≥ para Inc. Revista La columna de su autor titulada "¬ŅCrecimiento lento significa muerte lenta?" su tono es completamente diferente a la pompa de autoconfianza ordinaria: suena introspectivamente, con incertidumbre, llena de dudas. Joel se preocupa por el r√°pido crecimiento de Atlassian y analiza si hay espacio para varios jugadores en el mercado.

Tuve que pensar Tenemos un gran competidor que est√° creciendo mucho m√°s r√°pido que nosotros. La compa√Ī√≠a cierra grandes negocios con grandes clientes corporativos ... Mientras tanto, nuestro producto es mucho mejor y somos una empresa bien administrada, pero eso no parece importar. Por qu√©

√Čl decide hacer dos cosas. Primero, agregue todas las caracter√≠sticas a FogBugz :

La tarea del equipo de desarrollo para 2010 es eliminar cualquier raz√≥n posible por la cual los clientes pueden comprar basura de nuestros competidores solo porque hay una peque√Īa funci√≥n sin la que supuestamente no pueden vivir. Honestamente, no creo que sea muy dif√≠cil.

En segundo lugar, cree un equipo de ventas corporativo . Joel admite que no es fuerte aquí y considera que esta tarea es desagradable.

No s√© c√≥mo funcionaron estas medidas. Joel mencion√≥ por √ļltima vez a FogBugz en su blog en mayo de 2010 , anunciando brevemente una nueva versi√≥n.

Nueva esperanza


Y esto es lo que sucedió:

En el √°rea del d√©cimo aniversario de Fog Creek Software, comenc√© a pensar: para mantener a nuestros empleados motivados por otros diez a√Īos, necesitamos comenzar a trabajar en algo nuevo.

Por lo tanto, se dividieron en dos equipos, cada uno de los cuales hizo un prototipo de un nuevo producto. La idea ganadora se creó en el espíritu de un tablero kanban , un tablero fuera de línea real que a menudo se usa en proyectos de desarrollo de software: generalmente parece notas organizadas en columnas en un tablero.

Joel introdujo este programa como una herramienta de administración en un nivel más alto que FogBugz:

Honestamente, con todo este sofisticado software para "gesti√≥n de proyectos", nunca pude rastrear adecuadamente qui√©n est√° trabajando en qu√© ... Como fundador de dos compa√Ī√≠as, camin√© por los pasillos y vi a docenas de personas a las que se les paga por sentarse en las computadoras ... y no ten√≠a idea de si estaban haciendo su trabajo correctamente o si consideraban importante lo que en realidad podr√≠a no importar.





Al crear Trello, los desarrolladores de Fog Creek tuvieron la oportunidad de usar tecnologías modernas:

Utilizamos tecnolog√≠a avanzada, por lo que no est√° exento de sacrificios. Nuestras heridas de desarrollador est√°n dispersas por MongoDB, WebSockets, CoffeeScript y Node. Pero ahora est√°n interesados. En el ajetreado mercado laboral actual, los programadores talentosos deciden mucho sobre en qu√© quieren trabajar. Si les das un producto interesante ... les gustar√° y amar√°n su compa√Ī√≠a.

Trello admitió complementos desde el principio, por lo que los desarrolladores de terceros comenzaron a ayudar:

Los complementos y las API tienen la máxima prioridad ... Nunca haga un producto usted mismo si puede proporcionar una API básica, y los usuarios valiosos ... lo harán por usted. Existe una regla para el equipo de Trello de que si alguna función puede implementarse a través de un complemento, entonces debe implementarse de esta manera.

Los programadores, por supuesto, entendieron de inmediato los beneficios de Trello, pero no hab√≠a nada espec√≠fico en la herramienta para el desarrollo de software espec√≠fico. Joel describi√≥ a Trello como una herramienta √ļtil para "todo lo que quiera compartir listas con otras personas". Pronto, Trello comenz√≥ a usarse para organizar todo en una fila: desde cenas semanales hasta bodas y refugios para perros .

Mientras que FogBugz era un producto vertical , orientado a un nicho de mercado específico, Trello era un producto horizontal adecuado para cualquier cosa. Joel considera que el "movimiento horizontal" de Fog Creek es correcto en ese punto:

Es casi imposible crear un producto horizontal grande, √ļtil en todas las √°reas. No puede ser costoso, porque compite con otros productos horizontales que pueden absorber sus costos de desarrollo para una gran cantidad de usuarios. Este es un alto riesgo y una gran recompensa: este camino no es adecuado para una startup joven, pero es una buena idea para un segundo o tercer producto de una empresa madura y estable como Fog Creek.

Para escalar r√°pidamente a un gran n√ļmero de usuarios, Trello se ofreci√≥ inicialmente de forma gratuita. M√°s tarde present√≥ un plan de negocios .

En 2014, Trello se destac√≥ como una empresa independiente. Tres a√Īos despu√©s, vendi√≥ m√°s de $ 425 millones con m√°s de 17 millones de usuarios. Ir√≥nicamente, el comprador era Atlassian, el viejo enemigo jurado de Fog Creek.

Mientras tanto, volviendo a casa ...


Fog Creek continuó desarrollando otro nuevo producto, un entorno de programación colaborativa llamado HyperDev , que luego pasó a llamarse GoMix y luego Glitch .

Al mismo tiempo, el sistema FogBugz se congel√≥ en la oscuridad. En 2017, alguien decidi√≥ que FogBugz es un nombre tonto, y el esfuerzo de ingenier√≠a fue cambiar el nombre del producto como Manuscrito . Un a√Īo despu√©s, hace solo unos meses, Fog Creek vendi√≥ el producto a una peque√Īa empresa, DevFactory , que inmediatamente le devolvi√≥ el nombre de FogBugz .

Bajo el liderazgo del CEO Anil Dash, Fog Creek se convirti√≥ en una compa√Ī√≠a de un solo producto y cambi√≥ su nombre a Glitch .

Conclusiones


Tengo muchos pensamientos sobre esto.

La clave para entender la historia es que a Fog Creek no siempre le importó tanto el seguimiento de errores como el empoderamiento de los programadores , comenzando por el suyo:

La tarea principal: crear condiciones de trabajo cómodas. Hicimos cuentas personales para los empleados, solo volaban en primera clase, trabajaban 40 horas a la semana, recibían almuerzo gratis, sillas Aeron y las mejores computadoras. Compartimos nuestra ingeniosa fórmula con el mundo: excelentes condiciones de trabajo → excelentes programadores → excelente software → ¡ganancias!

Sobre la base de esta "f√≥rmula", se puede llegar a una conclusi√≥n l√≥gica y alentadora: Fog Creek construy√≥ un negocio en torno a la felicidad de los desarrolladores. Esto afect√≥ tanto a los productos de la compa√Ī√≠a como a su "sistema operativo" interno. El primer producto, un rastreador de errores, sirvi√≥ de base para el lanzamiento de un nuevo producto que resolvi√≥ un problema similar de una manera m√°s abstracta.

Seg√ļn Joel, parece que la historia de Trello no es tanto una b√ļsqueda de un nuevo negocio como oportunidades para apoyar la motivaci√≥n y la participaci√≥n de los desarrolladores de Fog Creek . Un producto por valor de medio bill√≥n de d√≥lares fue solo un efecto secundario agradable.

Sin embargo, un poco triste c√≥mo termin√≥ todo para FogBugz. No creo que los desarrolladores de Fog Creek estuvieran particularmente felices en los √ļltimos d√≠as antes de la venta.

Est√° claro que hubo proyectos m√°s importantes y m√°s grandes: Stack Overflow, Trello y Glitch, cada uno individualmente es mucho m√°s √ļtil y m√°s valioso que FogBugz; y es imposible que una persona haga un seguimiento de todo. Por lo tanto, no puedo culpar a nadie, en particular, por la p√©rdida de inter√©s en FogBugz con una base de c√≥digo de 20 a√Īos y una fuerte competencia en el mercado. ¬°Pero los usuarios leales al menos encontraron un buen hogar y no recibieron un medicamento para el ocaso!

Sin embargo, la parte sentimental de m√≠ preferir√≠a honrar m√°s honrosamente la herencia de todos los involucrados en la creaci√≥n y el uso de este producto en los √ļltimos a√Īos.





6. FreshBooks y BillSpring



Nota: icono de operación encubierta

El artículo ha crecido más de lo que esperaba, pero no puedo dejar de lado esta historia. Espera, habrá un giro inesperado.

Detenme si lo escuchaste antes


A principios de la d√©cada de 2000, Mike McDerment ten√≠a una peque√Īa empresa de dise√Īo. Decidi√≥ que el software de contabilidad era demasiado complicado, por lo que utiliz√≥ Word y Excel para la facturaci√≥n.

Todo funcionó bien hasta un caso :

El momento crítico llegó cuando solo el caso guardó una factura importante del cliente: simplemente hice clic en el botón deseado. Sabía que tenía que haber una mejor manera, así que pasé las siguientes dos semanas programando un prototipo que sería la base de FreshBooks de hoy.

Mike es dise√Īador, no programador, pero √©l y los dos cofundadores lograron armar una herramienta lo suficientemente buena como para que varias personas paguen $ 10 por mes por usarla. El negocio tard√≥ casi cuatro a√Īos en abandonar el s√≥tano de la casa paterna.

Para el d√©cimo aniversario del programa (¬Ņle suena familiar?) Freshbooks se ha convertido en una empresa rentable con m√°s de 10 millones de usuarios y 300 empleados.

Pero hubo un problema. Para cuando la compa√Ī√≠a logr√≥ contratar programadores "reales", ten√≠an un mill√≥n de l√≠neas de "c√≥digo fundador". Un analista externo revis√≥ la base de c√≥digo y concluy√≥:

‚ÄúLa buena noticia es que has resuelto la tarea m√°s dif√≠cil. Descubriste c√≥mo construir un negocio y tienes un producto que le gusta a la gente. La mala noticia es que ustedes est√°n poco versados ‚Äč‚Äčen tecnolog√≠a ‚ÄĚ.

M√°s importante a√ļn, era imposible implementar las ideas existentes en un producto existente:

Fundamos la compa√Ī√≠a hace m√°s de diez a√Īos, el mundo cambi√≥ y aprendimos mucho sobre el desarrollo de programas y las necesidades de empresarios individuales, que se est√°n volviendo cada vez m√°s en la sociedad ... sab√≠amos que se necesitaban algunos esfuerzos para mantener a FreshBooks actualizado en cinco a√Īos.

MacDerment está familiarizado con la sabiduría convencional de que no puede reescribir un sistema desde cero:

Reescribir el c√≥digo desde cero es el mayor riesgo para una compa√Ī√≠a de software. Lo m√°s probable es que ni siquiera termines el proyecto. Tomar√° m√°s tiempo de lo planeado y costar√° m√°s. El resultado final puede no ser atractivo para los clientes. Y no hay garant√≠a de que la nueva plataforma sea realmente mejor que la anterior. La regla n√ļmero uno en el software es no reescribir su software.

Por lo tanto, hicieron varios intentos para limpiar el desorden sin reescribir el sistema desde cero; pero "reemplazar neum√°ticos en el camino" no fue posible.

Lo que sucedió después puede sorprenderte


McDermint fue visitado por la idea de crear en secreto un FreshBooks "competidor".

Fund√≥ una compa√Ī√≠a completamente nueva en Delaware llamada BillSpring. Ella ten√≠a su propio sitio web, marca y logotipo. Intentando no conectar a las dos compa√Ī√≠as, instruy√≥ a un abogado externo para que desarrollara nuevos documentos para ella.

El equipo de desarrollo ha implementado pr√°cticas de desarrollo √°giles basadas en el libro de Jeff Gottelf y Josh Seiden "Lean UX: Dise√Īando excelentes productos con equipos flexibles" : equipos scrum e iteraciones semanales con comentarios de clientes reales. MacDerment les pidi√≥ que actuaran como una startup y lo tomaran como inversionista de riesgo:

“Tienes cuatro meses y medio. Si ingresa al mercado, obtenga más dinero. De lo contrario, el final ".

El equipo logr√≥ liberar MVP unos d√≠as antes de la fecha l√≠mite. Compraron palabras clave de AdWords para atraer tr√°fico y ofrecieron cuentas gratuitas a los usuarios durante el primer a√Īo. Pronto aparecieron los clientes, y comenzaron los r√°pidos ciclos de iteraci√≥n del producto real.

Al final del primer a√Īo, BillSpring comenz√≥ a cobrar. En alg√ļn momento, el nuevo producto recibi√≥ una evaluaci√≥n inesperada de calidad :

"Una persona llamó para darse de baja de FreshBooks e ir a nuestra nueva empresa", dice McDermint. "Fue un gran día".

Pronto levantaron el velo del secreto e informaron a los clientes de BillSpring que se trataba de un producto FreshBooks, y también informaron a los clientes existentes de FreshBooks que pronto llegaría una nueva versión.

Poco a poco, los clientes de los FreshBooks "clásicos" fueron admitidos en la nueva versión, pero siempre podían volver a la anterior si lo deseaban.



Conclusiones


El proyecto secreto de FreshBooks no era barato: seg√ļn McDermint, gastaron $ 7 millones en √©l. Sin embargo, despu√©s de m√°s de una d√©cada de crecimiento, recaudaron $ 30 millones en capital de riesgo √ļnicamente con sus propios recursos, por lo que hab√≠a dinero. No todos pueden permit√≠rselo.

Forbes estim√≥ los ingresos de FreshBooks en 2013 en $ 20 millones. Despu√©s de que se complet√≥ la actualizaci√≥n en 2017, ganaron $ 50 millones. No se sabe cu√°nto provino del nuevo producto, pero escribir el sistema desde cero claramente no desaceler√≥ el crecimiento de la compa√Ī√≠a.

MacDerment dice que el proceso de desarrollo e implementaci√≥n de nuevas caracter√≠sticas se ha vuelto m√°s r√°pido y f√°cil. M√°s importante a√ļn, ahora tienen un producto en sus manos que implementa las mejores ideas. Con esto no tiene miedo de mirar hacia el futuro.

Adem√°s, la experiencia adquirida ha cambiado la cultura de la empresa, en el buen sentido. Cuando pretendieron ser una startup, aprendieron a trabajar como startup. Las pr√°cticas Lean UX se han extendido a todo el equipo de desarrollo. Los clientes participan activamente en el desarrollo de nuevas funciones.

FreshBooks tom√≥ medidas extraordinarias para protegerse de posibles problemas: al introducir innovaciones bajo la marca falsa, los desarrolladores podr√≠an repensar completamente el programa y asumir grandes riesgos. Incluso en el peor de los casos, no da√Īar√°n la marca existente.

Todo parece un poco extremo. Quiz√°s tales medidas no eran necesarias. Pero este es un recordatorio de la gravedad de las apuestas.



Algunos pensamientos


En general, se acepta que es mejor evitar reescribir un programa desde cero y realizar mejoras graduales si es posible. En su mayor parte, estoy de acuerdo con eso.

Pero el consejo sugiere que al final obtenemos un producto original más un conjunto de nuevas características.

Pero, ¬Ņqu√© pasa si quieres eliminar la funcionalidad? ¬ŅO implementar alguna opci√≥n completamente diferente ? ¬ŅQu√© pasa si la experiencia surgi√≥ con las ideas de un enfoque fundamentalmente nuevo?

Mi conclusión de estas historias es la siguiente: tan pronto como comprenda que la versión actual es muy diferente del ideal imaginario , la nueva versión no debería lanzarse como reemplazo, sino en paralelo con la actual .

Cuando hay pensamientos para reescribir todo desde cero, puede valer la pena hacer otras preguntas. ¬ŅQuiz√°s crear tu propio competidor? Si mi producto es FogBugz, ¬Ņcu√°l ser√° mi Trello? Si esto es Visual Studio, ¬Ņc√≥mo ser√° mi c√≥digo VS?

Si comparamos el artículo de Spolsky sobre Netscape y la publicación de DHH sobre Basecamp, están de acuerdo en una cosa: el legado tiene valor.

La buena noticia es que no necesita tirar este valor para innovar.

Source: https://habr.com/ru/post/441456/


All Articles