Code-and-fix

Pues nada, ahora que ya me he quitado de encima el hablar un poco del ya viejo modelo en cascada para el desarrollo de software, me apetece hablar también de un método que siempre ha estado ahí. Es anterior incluso al modelo en cascada (algunos van a alucinar), pero todavía se usa hoy, por increible que parezca.

¿Qué método es este? Pues el del título, claro: Code-and-fix

¿En qué consiste? 
Este método, que va en contra de cualquier fundamento de la ingeniería del software, es muy simple y efectivo como veremos a continuación, ya que consta tan sólo de dos pasos:

  1. CODE: Programar algo tratando de que el resultado proporcione los objetivos deseados.
  2. FIX: Corregir el código para que funcione (normalmente añadiendo más código, y vuelta a corregir).

¿Qué os ha parecido? Pues esto que parece que me lo acabo de inventar, y que más bien es fruto de los desvaríos de una noche de juerga, es como se trabajaba antes….muy antes.

En uno de los libros de Steve McConnell encontramos esta frase: “Code-and-fix es un modelo poco útil, pero bastante común”. Y es que este método tan simple, se venía usando desde los primeros años del desarrollo de software. Sin embargo, su extensión era debida a su simplicidad, no a su efectividad. Al final, el código resultante podía funcionar…pero raramente consistía en lo que quería el cliente, adolecía de problemas de arquitectura, nula escalabilidad, etc. Hay quien todavía lo defiende para proyectos de pequeño tamaño (que no nos pase nada).

Pero claro…y si tenemos que entregar un proyecto con plazos imposibles (para ayer), de tamaño muy pequeño…¿no merece la pena programar desde el minuto 0? ¿No es mejor ponerse a teclear código ya? Pues no. Va a ser que no.

¿Cuál es el problema?
¿Pero si tenemos prisa, qué quieres que hagamos, Roberto? Pues lo que tenéis que hacer es parar a pensar primero. Sin un método, sin estrategia, no iremos a ninguna parte. El tema no es ponerse a hacer documentaciones extensas, ni requisitos complicados, ni diagramas de uso…Incluso para proyectos muy muy pequeños, existen metodologías que nos pueden ayudar.

Tal y como he leído en otro blog, el propio Steve McConnell nos ofrece un caso real donde la velocidad se consigue a través de método (simplificado, claro), técnica y disciplina: habla de un concurso de la “Australian Computer Society”, en el que se tenía que desarrollar una aplicación en tan sólo 6 horas. Mientras la mayoría de contrincantes se lanzaron a programar desde el primer minuto, una consultora participante utilizó una metodología de desarrollo formal, pero reducida: utilizando etapas de análisis y diseño y otras técnicas metodológicas. En esa ocasión, la empresa consultora perdió, pero porque el código entregado, no era la versión correcta. Habían tenido un fallo de gestión de la configuración. La misma empresa consultora, en un concurso similar posterior, ganó esta vez por goleada, ya que incorporaron técnicas de versionado que le evitaron el disgusto anterior. De nuevo, se demostró que la técnica y la ingeniería, superan el “tú ves programando, y luego si eso, ya lo corregiremos”.

Algunos ejemplos
Este ejemplo está obtenido del libro “Rapid Development”, de Steve McConnell. Pero hay más. El autor nos muestra un par de perlas relacionadas con el Code-and-fix:

  1. Código infernal. El modelo emprendedor, o de la empresa pionera, en el que se combina las técnicas de code-and-fix, y planificaciones ambiciosas, no funciona. Es un claro ejemplo de que dos mentiras no hacen una verdad.
  2. Sálvese el que pueda o abandonar el plan bajo presión. En muchas empresas, se produce la situación en la que tras un inicio de planificación, control, y supuesta buena gestión…se llega a una encrucijada en la que la acumulación de problemas y la asfixia de los plazos, problemas, y errores, hace que el equipo abandone toda planificación y se dedique a programar a toda costa, en un puro y duro “code-and-fix”. Esto también se produce cuando en un proyecto por entregas, una primera entrega desastrosa hace que la única decisión que se les ocurre a los gestores de turno es….abandonar toda planificación.

Pues nada, ahora ya sabéis qué nombre ponerle a eso que hacéis cuando entra el jefe por vuestra puerta y os grita histérico: “Correeeeeeeeeeee” “Produceeeeeeeeeeeeeeee”

Feliz programación

Anuncios

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s