Crónica de una muerte anunciada, por estrangulamiento -Introducción

“Crónica de una muerte anunciada” es una novela publicada en 1951 del autor Gabriel García Márquez que ciertamente no es muy de mi agrado, pero que posee el titulo perfecto para la serie de post que planeo publicar a lo largo de estos meses venideros.

Para los que no hayan leído la novela, acá un pequeño resumen extraído de Wikipedia:

En un pequeño y aislado pueblo en la costa del Caribe, se casan Bayardo San Román, un hombre rico y recién llegado, y Ángela Vicario. Al celebrar su boda, los recién casados se van a su nueva casa, y allí Bayardo descubre que su esposa no es virgen. Cuando lo descubre, devuelve a Ángela Vicario a la casa de sus padres, donde su madre la muele a golpes. Ángela culpa a Santiago Nasar, un vecino del pueblo.

Los hermanos Vicario –Pedro y Pablo-, obligados por la defensa del honor familiar, anuncian a la mayoría del pueblo que matarían a Santiago Nasar. Nasar no se entera, sino minutos antes de morir. Los hermanos matan a Santiago, después de pensarlo en varias ocasiones, en la puerta de su casa, a la vista de la gente que no hizo o no pudo hacer nada para evitarlo. A los 27 años, el mejor amigo de Santiago (el narrador) reconstruye los hechos de los que él fue testigo.”

La pregunta es, cuál es la motivación para que haya elegido el presente título, tan poco común para un blog técnico y además de la curiosidad, de ¿qué es lo que vamos a matar y de paso porque por estrangulamiento? Y principalmente, ¿porque vamos a tomar esa difícil decisión de eliminar algo?

Pues digamos que en este universo, no hay nada eterno, todo tiene un ciclo de vida, desde su concepción hasta su muerte, y esto ciertamente también se aplica al software.

¿Entonces hablamos de eliminar un sistema de software?, pues ciertamente si y no estamos hablando de cualquier sistema, hablamos de un tipo en particular, los sistemas empresariales.

Este tipo de sistema, tiene dos características importantes a mi parecer, la primera es que posee mucha lógica de negocios acumulada a lo largo de los años de vida y lo segundo que sus usuarios son muy renuentes a cualquier tipo de cambio.

Todo aquel que en algún momento haya trabajado en alguna aplicación empresarial sabe que tratar de remplazar una aplicación empresarial, con otra escrita desde “cero” es una locura, ya que ocasionaría un costo en tiempo y en dinero excesivo que no justificaría tomar el riesgo, sin embargo estos temores no son ciertos al cien por ciento. Hay veces en los que el mantener un sistema legado es por demás costoso, al punto que justifica embarcarse en esta riesgosa empresa de rehacer el sistema.

Por lo general un software empresarial después de haber sido puesto en producción entra en la fase explotación, donde se van arreglando bugs o agregando algunas funcionalidades no contempladas en la fase de desarrollo, esta fase muchas de las veces se extiende por años, sin embargo con el pasar del tiempo, el código del sistema se va ensuciando por varios factores, como por ejemplo funcionalidades nuevas que el cliente desea pero que requieren tocar partes estructurales del sistema para ser implementadas o por el crecimiento del equipo de desarrollo o el cambio de algunos miembros, que provocan que se asiente esta capa de suciedad sobre el código. Además no hay que olvidar también que algunas veces se construye software empresarial con ingenieros de software no muy experimentados que están encargados de la arquitectura del sistema y esa falta de experiencia hace que se agregue por lo general una capa extra de complejidad al sistema por un desarrollo no muy bien estructurado.

Este proceso común genera que este software, después de un periodo de unos 5 a 6 años, sea tan costoso, estresante y difícil de mantener que entra a una etapa que me gustaría denominarla etapa de “agonía”. Y cuando uno tiene un software en esta etapa, tenemos dos caminos, siendo el primero realizar un proceso de refactorización o el segundo camino que es construir uno nuevo.

Por lo general la idea de la refactorización es la más aceptada, tanto por los usuarios como por los dueños del software, ya que ofrece una menor cantidad de riesgos a simple vista, como costos bajos a corto plazo, tanto en tiempo como en dinero. Sin embargo muchas de las veces tomar este camino, no es el más adecuado y como una analogía para aclarar el punto, usemos autos.

Supongamos que nuestra aplicación en etapa de agonía, es un Volkswagen Golf 1990 como el de la primera fotografía y después de refactorizar obtendremos el auto de la segunda fotografía:

before

after

Ciertamente, después del proceso de refactorización, el producto se ve mucho mejor, sin embargo como podemos verlo gráficamente en la fotos y como sucedería con una aplicación, a pesar de que se hicieron cambios, aun se ve y se siente como un auto de 1990 ya que hicimos mejoras sobre la carrocería y el chasis de un auto de 1990 con materiales que datan de 1990, lo cual nos limita para que podamos obtener un producto mucho mejor y más acorde a la fecha.

Ahora supongamos que decidimos tomar el camino de rehacer la aplicación, el resultado que obtendríamos sería algo así:

Golf-GTI-2014-nunca-igualado

Ciertamente será más costoso a corto plazo en dinero como en tiempo, pero nos entregara un resultado más satisfactorio, porque no tendremos las limitantes que conlleva usar un chasis y una carrocería de más de 10 años de antigüedad, de igual modo con nuestro proyecto de software hecho desde “cero”, no tendremos la limitantes de un diseño de hace muchos años. Además de que nos proveerá algunas de las siguientes ventajas:

  • Uso de tecnología moderna, hace 10 años, no existía por ejemplo ASP.NET MVC o WPF
  • Mejor adaptación a los requerimientos actuales, 10 años antes, solo usábamos PDAs para leer emails y un poco más, al día de hoy usamos Tablets, Smartphones y PC con pantallas táctiles en conjunto para realizar muchas tareas empresariales.
  • Crear una aplicación desde “cero”, apasiona a los desarrolladores.
  • Uso de nuevas técnicas de prevención de errores, como las pruebas unitarias.
  • Menor costo de mantenimiento de tecnologías legacy, usar componentes y Frameworks de última generación, en aplicaciones con un diseño estructural de hace 10 años, requiere más esfuerzo para que se adapte a estructura antigua.

Por último, mencionar un punto importante y por el cual muchos de los riesgos que a simple vista parecen muchos, no lo son tantos y es que cuando la primera versión de la aplicación empresarial fue desarrollada, los requerimientos no eran para nada claros lo cual hizo que en muchas de las ocasiones el cliente no obtuviera lo que deseaba o lo obtuviera con mucho retraso o por partes, sin embargo si rehacemos la aplicación por segunda vez, ciertamente no estaremos empezando desde cero, ya que sabremos realmente que quiere el usuario y como lo quiere. Volviendo a la analogía de los autos, cuando desarrollamos la primera versión, solos sabíamos que el usuario quería un automóvil, no sabíamos si quería 3 o 5 puertas o si quería un motor con turbo o si prefería gasolina en vez de diésel, sin embargo para cuando lo rehacemos, sabemos que el usuario quiere un auto de tres puertas con un motor a gasolina de 3.2 litros, con un sistema biturbo y con un sistema de cambios de velocidad manual de 5 velocidades. Ciertamente errar en la segunda vez es mucho más difícil sabiendo lo que se desea obtener, además de que tendremos la aplicación legacy para comparar, este es el motivo por el cual uso el “cero” en muchos de los párrafos anteriores.

¿Qué enfrento y como la mato? – Van Helsing

Ya habiendo sentado las bases de porque es mejor tomar la opción de rehacer el sistema, solo queda ponerse las manos a la obra y como diría Van Helsing, solo es necesaria una pregunta doble: ¿Qué enfrento y como la mato? La respuesta a la primera parte de la pregunta varía de sistema a sistema y cada uno sabe a qué clase de sistema legacy se enfrenta, ahora la segunda parte es un poco más clara, y diremos que una de las mejores maneras de eliminar a ese sistema legacy es a través de la estrangulación.

Se preguntaran porque la estrangulación, y la respuesta es para la reducción de riesgos, como indica muy bien Matin Fowler:

“The most important reason to consider a strangler application over a cut-over rewrite is reduced risk. A strangler can give value steadily and the frequent releases allow you to monitor its progress more carefully. Many people still don’t consider a strangler since they think it will cost more – I’m not convinced about that. Since you can use shorter release cycles with a strangler you can avoid a lot of the unnecessary features that cut over rewrites often generate.” — Martin Fowler, Chief Scientist, ThoughtWorks, on The Strangler Pattern

La analogía que plantea Martin en su blog, es genial, pero me gustaría cambiarla por la de una Boa Constrictora, ya que la Boa es mucho más rápida y esto tiene que ver desde el punto de que si nuestro nuevo sistema tarda mucho tiempo en ser lanzado, podría ser considerado un fracaso, además de que tiene que ser letal contra el sistema legado, propiciando que el usuario final quiera saltar al nuevo sistema ni bien tenga la oportunidad por los beneficios que le ofrece, ya que casi de seguro, durante un tiempo tendremos los 2 sistemas funcionando en paralelo.

Estrangulación en Directo

Al principio de esta entrada mencione, que esto es el primer post de una serie de posts y esto es porque tengo la intención de estrangular un sistema e ir describiendo el proceso para que sea como una guía ejemplificada de como se lo debe hacer, además de que el describir el proceso me ayudara a supervisar el proceso.

En mi próxima entrada describiré el sistema a estrangular y que características debería tener el nuevo sistema, aunque advierto que no hare mucho énfasis en los detalles del sistema ya que es un sistema interno de la empresa en la que trabajo por lo que no puedo dar detalles, así que procurare que sea lo más general posible.

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s