¿Por qué el código de reescritura puede ser startup & semi; suicide

July 17|1 Vistas|

Resumen: (Nota del editor: El empresario en serie Steve Blank es el autor de Cuatro pasos para la Epifanía. Esta historia apareció originalmente en su blog.) Los beneficios del desarrollo ágil y del cliente y las características mínimas establecidas son retro

Advertisement

(Nota del editor: El empresario en serie Steve Blank es el autor de Cuatro pasos para la Epifanía. Esta historia apareció originalmente en su blog.)

Los beneficios del desarrollo ágil y del cliente y las características mínimas establecidas son retroalimentación continua del cliente, iteración rápida y poco código desperdiciado. Pero con el tiempo si los desarrolladores no son cuidadosos, el código escrito para encontrar clientes tempranos puede volverse difícil de manejar, difícil de mantener e incapaz de escalar. ¿Por qué el código de reescritura puede ser startup & semi; suicide

Irónicamente se convierte en la antítesis de ágil. Y la magnitud del problema aumenta exponencialmente con el éxito de la empresa. ¿La solución lógica? "Re-arquitecto y volver a escribir" el producto.

Para una empresa en un mercado que cambia rápidamente, eso es generalmente el principio del final.

Recientemente almorcé con un amigo que fue fundador técnico de su compañía y ahora es su presidente. (Él contrató a un ejecutivo operativo como el CEO hace unos años.) Él quiso hablar sobre un problema que estaba en su mente.

"A medida que hemos crecido nos hemos vuelto cada vez menos receptivos a las cambiantes necesidades del mercado y de los clientes", dijo. "Si bien nuestros ingresos se ven bien, podemos estar fuera del negocio en dos años si no podemos mantenerse al día con los rápidos cambios de nuestros clientes en las plataformas. Nuestro CEO no tiene antecedentes tecnológicos, pero está frustrado de que no pueda obtener las nuevas características y plataformas que quiere (Facebook, iPhone y Android, etc.). En la última junta directiva, nuestro vicepresidente de ingeniería explicó que la raíz de nuestra Problemas era "nuestro código ha acumulado una tonelada de" deudas técnicas ", es un código muy feo, y no es la forma en que lo habríamos hecho hoy. Le dijo a la junta que la única manera de entregar estos cambios es volver a escribir nuestro producto. "

Mi amigo añadió: "Suena lógico para el CEO, así que está a punto de aprobar el proyecto".

"Bueno, ¿la junta no le leyó el acto de disturbios cuando oyeron esto?" Le pregunté.

"No", respondió mi amigo, tristemente sacudiendo la cabeza, "el resto de la junta dijo que sonaba como una buena idea".

Con algunas preguntas más me enteré de que la base de código, que había crecido ya, todavía tenía vestigios del código exploratorio original escrito en los primeros días cuando la compañía estaba en la fase de descubrimiento del desarrollo del cliente. Los diseños de ingeniería realizados en ese entonces con el fin de averiguar el producto no eran los diseños adecuados para la tarea actual de la compañía de expandirse a nuevas plataformas.

Le recordé a mi amigo que nunca había sido un gerente de ingeniería así que cualquier consejo que podría darle era sólo de alguien que había visto la película antes.

CEO de cara a la "reescritura" problema al menos una vez en su mandato. Si se trata de un ejecutivo operativo sustituido por un CEO técnico fundador, entonces parece una decisión fácil: solo escuche a su VP de ingeniería comparar el programa de una reescritura (corta) con el calendario de adaptación del código antiguo al nuevo Propósito (largo).

En realidad esto es una elección de tontos. El equipo de ingeniería puede conocer la dificultad y los problemas de adaptación del código antiguo, pero no tiene idea de las dificultades y problemas que tendrá que enfrentar al escribir una nueva base de código.

Un CEO que había vivido una debacle de una reescritura o entendido la complejidad del código sabría que con el equipo de ingeniería original ya no existe, las probabilidades de volver a cometer los viejos errores son altas. Añada a eso la introducción de nuevos errores que no estaban allí la primera vez, la ley de Murphy dice que el optimismo desenfrenado probablemente convertirá la reescritura de un año en un proyecto de varios años.

Mi observación fue que el CEO y VP de Ingeniería estaban confundiendo causa y efecto. Los clientes no están pidiendo código nuevo. Ellos están pidiendo nuevas características y plataformas - ahora. Los clientes no les importa si se entrega a través de código espagueti, nave espacial extraterrestre o un producto completamente nuevo. Mientras que la reescritura del código está pasando, los competidores que no están enamorados con pureza arquitectónica agregarán funciones, plataformas, clientes y cuota de mercado.

La diferencia entre poder agregarlos ahora en comparación con un año o más en el futuro podría ser la diferencia entre el crecimiento de los ingresos y la salida del negocio.

Quizás el efecto secundario más peligroso de embarcarse en una reescritura de código es que la decisión condena el código anterior antes de que exista una alternativa viable. ¿Quién va a querer trabajar en el viejo código con todos sus problemas cuando el VP Ingeniería y CEO han declarado el nuevo código para ser el futuro de la empresa? El viejo código es tan bueno como muerto el momento de gestión introduce la palabra "reescribir".

Como consecuencia, el CEO no tiene retroceso. Si la programación de VP Engineering tarda cuatro años en vez de un año, no hay manera de hacer progreso incremental en las nuevas características durante ese tiempo.

Sugerí que esto parecía un fracaso de la imaginación en el VP de Ingeniería - hecho peor por un CEO que nunca ha vivido una reescritura de código - y compuesto por un consejo que también no lo recibe y no ha desafiado a ninguno de ellos por Una solución creativa.

¿Mi sugerencia a mi amigo? Dado lo dinámico y competitivo que es el mercado, este movimiento es un asesino de la compañía. La heurística debe ser no volver a escribir el código base en las empresas, donde el tiempo de comercialización es crítica y las necesidades del cliente cambiar rápidamente. "Vuelve a escribir puede tener sentido en mercados en los que el tiempo de ciclo es largo competitiva.

Le sugerí que se acostara en las vías delante de este tren en la reunión del consejo. Forzar al CEO a articular qué características y plataformas necesita cuando y qué medidas tiene para gestionar el riesgo de programación. Averiguar si un enfoque de ingeniería completamente diferente era posible. Hacer la elección equivocada en este tipo de materia puede crater una empresa. Esto era algo que valía la pena la pelea en la reunión del consejo.

Artículos relacionados

Popular

Último