No creo que exista algo que cree mas panico, ira y frustración a un desarrollador que  tener que adaptar cambios a un sistema ya hecho por otro equipo de desarrollo. En estos tiempos ‘googlegianos’  podemos encontrarnos con pedazos de codigo que otro hizo dentro de nuestras aplicaciones, es lo mas comun, pero como siempre el core del sistema sigue siendo creación del desarrollador/arquitecto/programador que lo realizo ya que corresponde a la capa del negocio que se esta pretendiendo automatizary no hay nada en el mundo que haga que encontremos esto en otro lado por mas que lo querramos.

Para que un desarrollador  tenga el desagrado de llegar a mantener o ampliar un aplicación que otro haya realizado pueden ocurrir 3 escenarios:

• Eres del departamento de mantenimiento y no te queda otra.
• A alguien se le ocurrio la brillante idea que si usabamos esta aplicacion que otra empresa ‘hermana’ hizo reduciriamos los tiempos de desarrollo.
• El desarrollador original del producto se fue y recien te contrataron ugentemente para que hagas unos pequeños cambios en esta.

En cualquiera de los 3 escenarios que me imagino lo primero que sucederá es que entre en juego el tan mencionado ego de los desarrolladores, donde en primera instancia veran con cara de pocos amigos ese pedazo de codigo que el no hizo y veran la forma de denigrarlo de alguna forma. Luego de superado su incial esceptisismo hacia este sistema tendran que comenzar a revisar su funcionamiento a detalle ty pasar el segundo paso que es encontrarse con muy poca documentacion sobre el trabajo desarrollado(excepto la gente de un departamento de mantenimiento que tal vez pueda exigir esto), el resto de los escenarios que planteo, el nuevo equipo desarrolladro se encontrara con un autismo del otro lado debido a alguna falla de comunicación inter-empresa o sencillamente porque el creador original de la aplicación no esta mas en la organización o lo mas comun, los tiempos no dieron para documentar por la premura de la entrega del producto. En cualquier sentido se encontrana miles de lineas de codigo que al inicio no tendran sentido mas que un funcionamiento de pantallas y que para el usuario probablemente no sirvan ya que eso es lo que quiero pero deseo agregarle, esto, aquello, etc. Y esos pequeños detalles son los que generaran de ahora en adelante la curva exponenacial de erorres de la aplicacion en contraste de la curva d ela bañera de los equipos electronicos(en cualquier caso revisarse cualquier libro de Ing. del Software para saber de que hablo).

Cuando el equipo desarrollador logra al fin ‘empaparse’ del negocio que la aplicación original hacía y agregado la nueva funcionalidad pueden ocurrir ahora 2 nuevos escenarios, que generamos un apice completamente nuevo con lo cual la aplicación seguira siendo mantenible en el tiempo, o sencillamente desarrollamos un ‘frankestein’ ya que alteraron el core del negocio original y se agrego otras funcionalidades que el sistema original no satisfacía, con lo cual la mantenibilidad de esta aplicación solo la conoce el neuvo equipo de trabajo ya que el grupo anterior si intenta hacer uso de ella se encontrara con un sistema completamente diferente al que pensarono entregaron.
Tristemente esto uno de los casos que mas frecuentemente nos encontramos en nuestro ambiente laboral. Por ejemplo gente como SAP recomienda usar lo mas estandar posible su sistema evitando agregar muchas personalizaciones al mismo (las conocidad ‘Z’) para garantizar que cuando se realice el cambio de versión esta pueda realizarse sin traumas. ¿Será esta la verdadera razón o ellos conocen mejor el problema que muchas instalaciones SAP cambien el sistema en demasiadas partes?.

Ahora, si el legacy code llega a ser tan pernicioso  ¿por que se estila comprar u obtener sistemas con fuentes para adaptarlo al negocio?. La respuesta podría ser lo que inicialmente se piensa, que con algo que mas o menos se parezca a mi negocio podría hacer que mi desarrollo se haga en menos tiempo, ¿pero realmente se evaluan bien lo que hace este sistema que se adquiere con lo que deseo o sencillamente se cumple una expectativa de elección presionado por otros niveles ?. Si al caso vamos, mucho proyectos open source sone exitosos al permitirnos adaptarlos a nuestra necesidad, pero la recomendación en este caso es que cada cual tome el proyecto base, que desde mi punto de vista tiene los servicios básicos del negocio y lo adapte a su necesidad, pero nunca tomar uno ya adaptado porque este ya contendría el modelo de negocio difernete al nuestro a menos que la nueva funcionalidad agregada sea algo completamente estandar y si mejore la calidad del proyecto base y no lo entorpezca o la haga inmantenible.

Continuando el tema de la elección del sistema, tambien se cae en ver muy por encima al sistema y no se observa en profundidad la arquitectura del mismo(no vale que te muestren los diagramas de siempre, tristemente la implementación puede cambiar esta realidad), pasando que luego de haberlo elegido se den cuenta que adaptar los nuevos cambios  conlleva a una reprogramación excesiva del negocio. Esta muy claro que si se toma el tiempo de hacer una evaluación exhaustiva del mismo se corre el riesgo de desecharlo por no cumplir con los requerimeintos mismos y sumado a esto el haber perdido este tiempo cuando se pudo haber aprovechado en codificar o hacer uno nuevo desde 0.

¿Realmente sirve usar un Legacy Code?, la respuesta es muy ambigua, ya que los mismos estan alli, son muchas veces el core system de las empresas y hay que seguir ampliandolos debido a cambios del modelo de negocio, pero desde mi punto de vista, un sistema medular de cualquier empresa nunca debería ser realizado con codigo prestado de otro lado, simplemente que por la garantía del proceso negocio este debería ser hecho en casa siempre para tener le modelo de negocio consistente; es un craso error pensar que usar algo de otro implica un ahorro ya que al final se genera un monstruo que con el transcurso del tiempo hara que la directiva diga: "El presupuesto de tu Gerencia coloca este sistema para hacerlo de nuevo", y la espiral arranca de nuevo, pero esto es otra historia