Una "reescritura" (o al menos un poco de refactorización) es a veces la mejor manera de avanzar cuando se da cuenta de que una solución no es escalable.
Un ejemplo de esto es un paquete de pintura que escribo en la década de 1980. Comenzó como un poco divertido trabajando en un mapa de bits de 16 colores. Cuando tenía 20 KB de código BASIC, pensé "Debería reescribir esto para que sea capaz de manejar 16 o 256 imágenes en color". Pero fue "demasiado trabajo". Cuando era de 50kB, estaba claro que realmente necesitaba ser reescrito, pero solo tomaría demasiado tiempo. Así que continué agregando código que dependía de que fuera una imagen de 16 colores, hasta que llegó al punto en que era de 140 kB y completamente imposible de reescribir. Siempre lamenté no haber mordido la bala cuando la reescritura fue solo de unas pocas horas de trabajo.
Otro ejemplo: trabajé en un paquete de arte vectorial que transmitía eventos alrededor de todos los objetos en su jerarquía de escenas. En las etapas iniciales tenía algunas decenas de objetos y, como dijo mi jefe, "podemos transmitir a más de 10.000 objetos por segundo", por lo que las transmisiones continuaron. Sugerí que los objetos interesados se suscribieran a los eventos que necesitaban para eliminar la ineficiencia, pero "no era necesario". 2 años (40 años de esfuerzo) más tarde, el programa se detenía por 2-4 segundos a la vez porque el gráfico de escenas contenía más de 500 objetos y los 2 eventos de transmisión habían aumentado a 40 o más.
Este patrón se ha repetido en varios proyectos en los que he estado involucrado a lo largo de los años: detecta un defecto de diseño serio o una deuda técnica y difiere en solucionarlo porque (a) no es un problema "todavía", y (b) costaría demasiado tiempo resolverlo ahora. A medida que pasa el tiempo, se convierte linealmente en un problema mayor, pero exponencialmente más costoso de arreglar. Por lo tanto, aunque es necesario corregir cada vez más, es más difícil justificar el costo de solucionarlo.
En estos casos, la deuda técnica o defecto de diseño debe resolverse como early como sea posible. Se necesitan agallas (si eres un gerente) o persuasión (si eres un subordinado) para retener tu agenda durante una semana, ¡pero imagina que no tienes más remedio que dedicar 2 meses a la reparación en un año!
Por supuesto, este argumento no se aplica a todos los casos. Debe evaluar el costo/beneficio de cualquier solución propuesta y considerar la escalabilidad del problema: si el problema es constante, puede solucionarlo por el mismo costo en cualquier momento en el futuro. Si cada clase nueva que agregas a tu sistema aumenta la falla, y esperas agregar cientos de clases nuevas, luego regresa y corrige ahora.
Edad. Cuando una tecnología ha visto mejores días * y * soporte para ella, en términos de programadores, se está reduciendo, es probable que sea hora de escribir algo nuevo. He reescrito los sistemas COBOL, DataFlex y VB6. Se puede argumentar que el soporte para estos sistemas todavía está disponible, pero la mayoría de los programadores quieren promocionarse con las últimas habilidades y, por lo tanto, dejan a las viejas tecnologías en el polvo. Entonces, si tiene problemas para encontrar un programador de DataFlex, entonces sí, probablemente sea hora de volver a escribir. –
¿Qué tal esto: qué pasa si construyes un nuevo producto basado en lo que aprendiste del proyecto anterior que la gente quiere reescribir? ¿Dejar el antiguo y no considerar el nuevo proyecto como parte de la misma línea? –