La Trampa de la Reescritura

Entonces, comencemos con ¿de dónde viene ese impulso? Y creo que hay tres razones principales. La primera es que no necesitas aprender nuevos conceptos, ¿verdad? Por ejemplo, digamos que es una aplicación de cliente, está escrita en React, pero a ti te gusta más Vue o Svelte o cualquier otra cosa, ¿verdad? Y al adentrarte en React, inmediatamente tienes esa sensación repulsiva de que realmente no quieres meterte en esto, ¿verdad? Entonces, si lo descartas y lo reescribes en tu pila preferida, ese problema desaparecería. Lo mismo ocurre con los lenguajes de programación, metodologías, lo que sea, ¿verdad? Todo lo que no estás acostumbrado a, inmediatamente dices tal vez no lo hagamos. La segunda cosa también es que alguien más construyó eso, ¿verdad? Entonces, si realmente te gusta cierta arquitectura, digamos por ejemplo que realmente te gusta la programación funcional, pero el producto actual está construido de una manera muy orientada a objetos, entonces, ja, ya sabes, esos dos mundos podrían no alinearse tan bien, ¿verdad? Y siempre se sentiría como un obstáculo familiarizarse con todo, ¿verdad? Y quizás ya te hayas dado cuenta de que hay un patrón aquí. Y el patrón no es necesariamente que las elecciones tecnológicas, las elecciones de lenguajes de programación, las elecciones de arquitectura sean mejores o peores. Es simplemente que son diferentes y que, intrínsecamente, si algo es diferente a lo que preferimos, tenemos que luchar contra ese impulso de simplemente desecharlo y convertirlo en algo que nos guste. Un colega mío una vez me dio el consejo de esperar 100 días antes de tomar decisiones técnicas importantes una vez que te unes a un nuevo trabajo, ¿verdad? Porque en 100 días puedes aprender mucho y también puedes descubrir si algo, una elección del pasado, es realmente peor de lo que querías usar. ¿Es un problema que sea orientado a objetos? ¿Debería ser funcional? O si esto fue simplemente tu reacción inicial a algo en particular y simplemente no te gustó antes, ¿verdad? Pero probablemente después de 100 días, también te acostumbraste y tal vez ya no sea tan malo. Personalmente, debo admitir que siempre acorté ese período a 50 días. Porque especialmente cuando era CTO, no pude convencer a mi CEO de esperar, ya sabes, casi un tercio de año antes de comenzar a tomar decisiones importantes. Simplemente comienza la vida y tienes que hacer lo que tiene sentido en ese momento. Ahora pasemos a la tercera parte. Y esa es la parte más egómana, ¿verdad? Si simplemente desechas todo, puedes trabajar de la manera que quieras, ¿verdad? Tú estableces todas las reglas. Esto definitivamente se siente cómodo, ¿verdad? La gran pregunta aquí es simplemente, ¿eso, ya sabes, tiene sentido a largo plazo, ¿verdad? ¿Tu forma de trabajar, por ejemplo, es compatible con la forma en que funciona la empresa, ¿verdad? Y sí, todas estas cosas que acabo de describir, inicialmente, podrían parecer buenas razones para comenzar desde cero, ¿verdad? Y definitivamente podemos convencernos de los beneficios de cualquiera de estas opciones. Pero la pregunta es, ¿realmente valen la pena? Y creo que rara vez lo hacen. Y aquí es donde entra la trampa porque inicialmente, si observamos estos proyectos, he dibujado dos líneas ficticias, esencialmente, la línea verde representa un proyecto de software existente y no lo reescribes, sino que intentas mejorarlo gradualmente, avanzar en el proyecto y mejorarlo. Y la línea morada representa la reescritura completa y las X son simplemente el tiempo en el eje X y el eje Y es el resultado.

¿Cuánto puedes lograr realmente? Y obviamente, si comienzas una reescritura, no hay nada allí, nada que te detenga. Puedes sacar muchas cosas al principio muy rápido. Incluso podrías engañarte pensando, wow, esta debe haber sido la mejor opción. Estamos tan rápidos. Todo se mueve rápido. Eso es genial, ¿verdad? Bueno, ya sabes, las personas que se quedan con el código existente e intentan mejorar gradualmente primero, tienen que lidiar con los detalles, aprender las elecciones arquitectónicas, ya sabes, ver qué hay y mejorar gradualmente el sistema en funcionamiento, básicamente. Y aquí es donde entra la trampa, realmente, ya sabes, esa falsa sensación de productividad al principio, es lo que creo que lleva a las personas a tomar esas decisiones de reescritura. Y te doy una pista, tal vez también sea bueno para tu carrera hacer esto, ¿verdad? Porque, no sé cuánto tiempo, ya sabes, las fases uno, dos y tres duran. Pero si te vas en la fase uno, o al final de la fase uno, todo lo que has hecho hasta ahora parece muy productivo. Has hecho un gran trabajo. Entonces podrías ser, ya sabes, el líder técnico realmente bueno que logra hacer las cosas y que hace las cosas que nadie más quería hacer. Y eso te ayuda a progresar, ya sabes, tal vez hazlo si es bueno para ti, pero yo no soy esa persona.

Pero, ya sabes, veamos todos estos detalles y comencemos con la fase uno. Ya he dicho que la reescritura será, ya sabes, rápida desde el principio. Implementarás rápidamente las primeras características. Harás lo básico, no sé, ya sabes, tener un flujo de registro, tener las primeras características importantes en marcha. Todo es rudimentario porque trabajas de forma iterativa y, ya sabes, haces todo lo necesario y siempre tienes algo que presentar a la gente. Mientras tanto, las personas que se quedan con el código existente probablemente tienen poco que presentar porque necesitan comprender todo lo que está allí. Necesitan averiguar, vale, ¿qué pertenece junto? ¿Cómo funcionan realmente las cosas? ¿Dónde están los casos límite y todas estas cosas? Entonces, en la fase uno, la reescritura se siente bien y avanzas, mejorando lo que ya está allí, pero no se siente tan bien porque parece que no estás progresando en absoluto.

Estas cosas comienzan a verse diferentes cuando entras en la fase dos porque lo que la reescritura pasó por alto por completo fueron, ya sabes, los problemas y los casos límite que la gente había encontrado antes. Esa gran base de código heredada probablemente no era tan complicada, solo, ya sabes, por pura coincidencia, pero probablemente por una razón. Así que nuestra gran reescritura en algún momento se encontrará con esa parte donde entran los casos límite, donde entran las peculiaridades y te darás cuenta de que, dado que no aprendiste todas estas cosas de antemano y ni siquiera te molestaste en entender por qué el antiguo sistema se convirtió en lo que era. Hiciste muchas suposiciones, construyendo tu nuevo software que simplemente no encajan bien con, ya sabes, esos casos límite y otros requisitos que tienes. Así que tienes que comenzar a retrabajar cosas. Tienes que encontrar la manera de incorporar otras cosas. Pero ya sabes, como has sido tan productivo antes, ¿verdad? La gente tiene la suposición de que, ya sabes, las cosas se moverán rápido y quieren que se muevan rápido y eventualmente terminarás agregando deuda técnica nuevamente, ¿verdad? Tienes que, ya sabes, tomar atajos, tratar de mantener ese impulso en movimiento, pero eventualmente lo que sucederá es que tu progreso se ralentizará, los resultados disminuirán y sí, simplemente tienes que navegar hacia el mismo desastre que el antiguo

Probablemente sabemos que deberíamos haberlo hecho así, pero bueno, ya sabes, el plazo se acercaba. Pero estas discusiones te ayudan a llevarte bien con las personas y también a comprender que las personas realmente, realmente tienen el deseo de construir lo correcto, pero ya sabes, el sistema que los rodea simplemente no les dio el apoyo que necesitaban para hacerlo realmente. Y, ya sabes, como líder, líder técnico, CTO, lo que sea, esto es ahora tu responsabilidad, esencialmente, ahora debes asegurarte de crear un sistema para ellos, donde puedan hacer el trabajo adecuado. Correcto. Y a veces también, ya sabes, también debes hablar con personas fuera del área de desarrollo, ¿verdad? Hablar con ventas, hablar con marketing porque, ya sabes, es probable que también hayan influido en tu architecture actual y necesitas comprender por qué ciertas cosas eran importantes, ¿verdad? Si estás en una startup, ya sabes, el dinero necesita entrar, ¿verdad? Así que a veces tienes que, ya sabes, sacar esa cosa que simplemente va a firmar el próximo acuerdo, porque de lo contrario la empresa ya no existiría. Estas son todas buenas razones para hacer, um, algunos atajos en la tecnología. Realmente no quería creer eso al principio de mi career. Ahora creo que entiendo mejor a algunos vendedores. Y esto también es lo tercero que debemos conocer del sistema, ¿verdad? Eres un grupo de personas y el departamento de ingeniería o I+D dentro de una empresa no es su propio universo. Hay factores a su alrededor que influyen en el sistema. El CEO, ventas, marketing, ya sabes, todos ellos esencialmente combinados. Y necesitas comprender cómo funciona la empresa para poder navegar en ella de una manera que puedas lograr, ya sabes, el éxito. Y, uh, esto no es una tarea fácil. Esto también requiere hablar mucho también con personas fuera de, um, uh, fuera de la ingeniería y también comprender sus necesidades. Como, ya sabes, ¿qué necesitan las personas? Y te daré el ejemplo, por ejemplo, ya sabes, cuando me uní como CTO, um, ya sabes, no podía creer lo que estaba viendo, ¿verdad? No había pruebas, no había una definición de lo que se suponía que debía hacer el producto. Um, no teníamos ningún informe de errores. Y el CEO siempre me pedía un plan para cuando se terminaran las características. Como, ya sabes, no puedo, no sé, ni siquiera sé qué hay. Así que no puedo decirte nada sobre cuándo se terminará lo próximo. Intenté explicar mucho y, en última instancia, no funcionó. Pero esto también se debe a que no reconocí completamente el sistema allí, ¿verdad? Porque el sistema con el CEO existente, el cliente existente, el director de clientes principales llevó a esto, ¿verdad? Y, ya sabes, no me molesté en comprender exactamente cuáles son sus necesidades y tratar de satisfacerlas siempre. Entré allí y simplemente con una especie de enfoque técnico completo, ¿quieres todo eso, verdad? Decir, está bien, sé que todo esto es malo. Necesitamos hacer esto, ¿verdad? Necesitamos agregar monitoreo. Necesitamos agregar algunas pruebas. Necesitamos agregar, ya sabes, algo de automation en torno a las versiones. Y luego podemos trabajar en el camino a través de las dificultades. Y, en última instancia, tampoco reescribí activamente, sino que mejoré lo que había. Y con eso, en última instancia, fallé en su opinión porque fue muy lento y, en última instancia, ya sabes, fui despedido cuando la curva comenzó a inclinarse cuando, ya sabes, no teníamos más errores de los que podíamos solucionar o cuando comenzamos a entregar características en un cronograma predecible o más predecible, um, donde, curiosamente, alguien más vino y el CEO contrató a alguien que hizo una reescritura completa y fueron súper rápidos. Y, en última instancia, recibí la noticia, dijeron, ya sabes, míralos, en un mes construyeron eso.

Entonces, en esencia, la conclusión es hacer lo que importa, ¿verdad? Um, no intentes estar ocupado, um, pero sabes, enfócate en las cosas que realmente, ya sabes, crean valor, ¿verdad? Tienes que salir de tu zona de confort. Y especialmente con eso, quiero decir, tienes que hablar con mucha gente y, uh, tienes que tratar de entender también las necesidades de las personas que te son tan ajenas. Para mí personalmente, siempre fue ventas, como, esto es un mundo completamente diferente. Um, necesitas reconocer que simplemente no tienes todas las respuestas. No lo sabes todo. Y está bien. Aprender es, ya sabes, como probablemente sabes, la parte más importante del trabajo, uh, y necesitas, ya sabes, vas a tener que aprender mucho más.

De acuerdo. Y al final, una vez que hayas descubierto todo eso, necesitas reconstruir las partes que realmente importan. Y esto es una charla en sí misma. Y sabes, tienes suerte porque ya di esa charla. Se llama, uh, abrazar el legado. Si quieres verla, la encontrarás en mi blog, uh, philbeazit.com, um, de acuerdo. Segmento de patrocinio terminado, pero en serio, ¿verdad? Muchas de las cosas que quieres rehacer al principio simplemente no son importantes. ¿Verdad? Um, las partes que realmente importan son todas las partes que crean valor para tus clientes y también crear valor para nuestros clientes podría significar que esencialmente te haga más rápido y te permita entregar software de alta calidad más rápido. ¿Verdad? Y, um, no hay una regla estándar para encontrarlas, pero supongo que lo harás. Confío en ti. Y con eso, te despido. Esto fue la trampa de la reescritura. Mi nombre es Phil Giese. Nos vemos por ahí.