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.