Economía para mejorar la calidad de vida

Este es un artículo muy interesante que me ví en la necesidad de traducir, lo comparto aquí porque lo estaré citando en el futuro, ya que creo que comparte una gran enseñanza experimental que debemos valorar. La traducción tiene varios errores, ojalá me ayuden en sus comentarios para corregirlos.

Artículo Original: Things You Should Never Do, Part I

Artículo en Castellano: Cosas que Nunca se Deberían Hacer, Parte I

Continúa Traducción libre hecha por el autor de este blog…. se recomienda ir a la versión original

Cosas que nunca debemos hacer.. Parte I

Netscape 6.0 está finalmente en su primer beta público. Nunca hubo una versión 5.0. La última versión, la versión 4.0, fue lanzada hace casi tres años. Tres años es un tiempo terriblemente largo en el mundo de Internet. Durante este tiempo,  Netscape se sentó , inútilmente, viendo a su cuota de mercado caer en picada.

Es un poco pelmazo de mi parte criticarlos por esperar tanto tiempo entre las distintas versiones. Ellos no lo hicieron a propósito, ¿o sí?

Bueno, sí. Lo hicieron. Lo hicieron cometiendo el único peor error estratégico que cualquier compañía de software puede hacer:

Decidieron volver a escribir el código desde cero.

Netscape no fue la primera empresa en cometer este error. Borland cometió el mismo error cuando compraron Arago y trataron de hacer dBase para Windows, un condenado proyecto que tomó tanto tiempo que Microsoft Access se los comió de almuerzo, y luego lo hicieron de nuevo en la reescritura de Quattro Pro desde cero y sorprendieron a las personas con algunas de las características que ya tenían. Microsoft hizo casi el mismo error, tratando de reescribir Word para Windows desde cero en un condenado proyecto llamado la Pirámide que se cerró, fue tirado y escondido bajo la alfombra. Por suerte para Microsoft, no había dejado de trabajar en la antigua base de código, por lo que tenían algo que embarcar, cometiendo simplemente un desastre financiero, no uno estratégico.

Somos programadores. Los programadores son en sus corazones arquitectos y lo primero que quieren hacer cuando llegan a un sitio es a arrasar el lugar dejarlo plano y construir algo grande. No estamos emocionados por la renovación incremental: el bricolaje, las mejoras, estar plantando una cama de flores.

Hay una sutil razón por la que los programadores siempre quieren tirar el código y comenzar de nuevo. La razón es que piensan que el antiguo código es un lío. Y aquí está una interesante observación: están probablemente equivocados. La razón por la que piensan que el antiguo código es un lío, es por una ley cardinal fundamental de la programación:

Es más difícil de leer el código que escribirlo.

Esta es la razón por la reutilización de código es tan difícil. Esta es la razón por la que todos en su equipo tiene una función diferente que les gusta utilizar para dividir las cadenas en los arrays de cadenas. Escriben su propia función, porque es más fácil y más divertido que averiguar cómo funciona la antigua.

Como corolario de este axioma, usted puede preguntarle a casi cualquier programador de hoy sobre el código en que trabajan. Y les dirá: «Es un gran lío peludo». «Nada más me gustaría más que tirarlo y empezar de nuevo.»

¿Por qué es un lío?

«Bueno», dicen, «mire esta función. Se trata de dos páginas! Nada de esto pertenece allí! No sé lo que hacen la mitad de estas llamadas a la API».

Antes que fuera enviada la nueva hoja de cálculo de Borland para Windows, Philippe Kahn, el colorido fundador de Borland, fue citado con mucho alarde en la prensa acerca de cómo Quattro Pro sería mucho mejor que la de Microsoft Excel, ya que fue escrito desde cero. Todo el código fuente era nuevo! Como si el código fuente oxidada.

La idea de que el nuevo código es mejor que el viejo es patentemente absurda. Código antiguo se ha utilizado. Ha sido probado. Gran cantidad de errores se han encontrado y han sido corregidos. No hay nada de malo con ello. No es que se adquieran los errores sólo por el hecho de estar sentados cerca de tu disco duro. Al contrario, nena! Se supone que el software es como un viejo Dodge Dart, que se oxida sentado en el garaje? o que el software es como un osito de peluche que no fue hecho con todos los materiales nuevos?

Volviendo a la función de 2 páginas. Sí, ya sé, es una simple función para mostrar una ventana, pero le ha crecido un poco de pelos y cosas sobre ella y nadie sabe por qué. Bueno, te diré por qué: esas son correcciones de errores. Una de ellas establece que los fallos que Nancy tenía cuando intentaba instalar la cosa en un equipo que no tiene Internet Explorer. Otro que fija un error que se produce en condiciones de baja memoria. Otro que fija un error que se produjo cuando el archivo está en un disquete y la cifra de usuarios en el disco en el centro. La llamada a LoadLibrary es fea, pero hace que el código trabaje en las antiguas versiones de Windows 95.

Cada uno de estos errores tomó semanas de uso en el mundo real antes de que fueran encontrados. El programador podría haber pasado un par de días reproduciendo el error en el laboratorio y reparándolo. Si es como un montón de errores, la solución podría ser una línea de código, o podría ser incluso un par de caracteres, pero una gran cantidad de trabajo y tiempo hay en estos dos caracteres.

Al tirar el código y empezar desde cero, usted tira todos esos conocimientos. Todos los errores corregidos que se recolectaron. Años de labor de programación.

Usted tira su liderazgo en el mercado. Usted está dando un regalo de dos o tres años a sus competidores, y créame, que es mucho tiempo en años de software.

Usted se está poniendo en una posición extremadamente peligrosa cuando esté enviando una versión anterior del código por varios años, completamente incapaz de hacer cambios estratégicos o de cualquier reacción a las nuevas características que exige el mercado, porque no tiene código que pueda enviar. Es posible que también acabe de cerrar el negocio durante ese período.

Usted está perdiendo una extravagante cantidad de dinero escribiendo código que ya existe.

¿Existe una alternativa? El consenso parece ser que la antigua base de código de Netscape era realmente mala. Bueno, podría haber sido malo, pero, ¿sabes qué? Funcionó bastante bien en un maldito montón de sistemas de computadoras del mundo real.

Cuando los programadores dicen que su código es un santo lío (como siempre lo hacen), hay tres tipos de cosas que están mal con ello.

En primer lugar, hay problemas de arquitectura. El código no es construido correctamente. La creación de redes de código saltan con sus propios cuadros de diálogo desde la mitad de la nada, lo que deberían haber sido manipulados en el código de la interfaz de usuario. Estos problemas se pueden solucionar, uno a la vez, moviendo con cuidado por el código, refactorizándolo, cambiando las interfaces. Esto lo puede hacer un programador que trabaje cuidadosamente y haciendo un control de cambios de una sola vez, para que nadie se vea perturbado. Incluso grandes cambios arquitectónicos se puede hacer sin tirar el código. En el proyecto Juno que pasó varios meses en re-arquitectura por un punto: sólo moviendo cosas, limpiando, la creación de clases base que tienen sentido y la fuerte creación de interfaces entre los módulos. Pero lo hicimos con cuidado, con nuestra actual base de código y no introduciendo nuevos errores o tirando código que funcionaba.

Una segunda razón programadores piensan que su código es un lío es porque es ineficiente. El código de rendering en Netscape se rumoreaba que era lento. Pero esto sólo afectaba a una pequeña parte del proyecto, que se puede optimizar o incluso reescribir. Usted no tiene que reescribir todo. Cuando la optimización de la velocidad, era el 1% del trabajo te daba el 99% de la explosión.

En tercer lugar, el código puede ser malditamente feo. Un proyecto que en realidad había trabajado en un tipo de datos llamado FuckedString. Otro proyecto había comenzado a cabo mediante el convenio a partir de las variables miembro con un guión bajo, pero más tarde cambió a la norma más «m_». Así que la mitad de las funciones que comience con «_» y la mitad con «m_», que parecía feo. Francamente, este es el tipo de cosa se puede resolver en cinco minutos con una macro en Emacs, no partimos de cero.

Es importante recordar que cuando se empieza desde cero no hay absolutamente ninguna razón para creer que se va a hacer un mejor trabajo que usted hizo la primera vez. En primer lugar, es probable que ni siquiera tienen la misma programación que el equipo trabajó en una versión, por lo que en realidad no tienen «más experiencia». Estás solo va a hacer la mayoría de los viejos errores de nuevo, e introducir algunos nuevos problemas que no estaban en la versión original.

El viejo mantra de construir algo para de tirarlo es peligroso cuando se aplica a gran escala de aplicaciones comerciales. Si usted está escribiendo código de forma experimental, es posible que desee romper la función que escribió la semana pasada cuando se piensa en un mejor algoritmo. Eso está bien. Si lo desea, puede refactorizar una clase para que sea más fácil de usar. Eso está bien, también. Pero tirar todo el programa es una locura peligrosa, y si realmente Netscape hubiera tenido una supervisión de un adulto con experiencia en la industria de software, puede que no se hubieran disparado en el pie tan feamente.

Artículo Original: Things You Should Never Do, Part I

Filed under: chile | Tagged: desarrollo, netscape, python |