El ciclo REAL del desarrollo de software

Ross McKenzie, en el foro de (x)Harbour, ha comentado a manera humorística el ciclo REAL del desarrollo de software, con mucho sentido del humor y otro tanto de razón he aqui lo que dice, cualquier semejanza con la realidad, es pura coincidencia.

1) El programador hace código que "piensa" que esta libre de bugs.

2) El producto es probado, y se encuentran 20 bugs.

3) El programador corrige 10 de los bugs y explica a la gente encargada de probar el software, que los otros 10 no son bugs son "nuevas características"

4) La gente encargada de probar el software continúa las pruebas, y encuenta que 5 de las correciones realizadas en el paso 3 no funcionan, de paso encuentran otros 15 bugs.

5) Se repiten los pasos 3 y4 tres veces mas.

6) Como es costumbre, y debido al excesivo optimismo del equipo de programación, se ha anunciado el lanzamiento del nuevo software con demasiada anticipación, el departamento de mercadotecnia comienza a presionar y.... se libera el software lleno de bugs.

7) El usuario final encuentra 137 bugs mas.

8) El programador original cobra su cheque por el desarrollo del software y se marcha de vacaciones,... nadie en la empresa sabe donde está.

9) Para salir del paso se integra un nuevo equipo de desarrollo que corrige los 137 bugs, peeeeerooooo, en el proceso crea 456 bugs mas.

10) El programador envia una postal desde las islas Fiji a los encargados de probar el software (que por cierto están mal pagados) y todo el equipo de pruebas renuncia.

11) La compañía es comprada por su competencia, la cual utiliza las ganacias adicionales que obtuvo por la venta de mas unidades del su software (que por cierto tenia 786 bugs) debido a que nuestro producto tardó demasiado en salir al mercado y cuando salio era bastante malo.

12) Se nombra un nuevo director por parte del nuevo consejo directivo de la empresa, el nuevo director, decide tirar todo a la basura y comenzar a escribir todo desde cero.

13) El programador (muy probablemente el desarrollador original que ha vuelto de vacaciones de Fiji) hace código que "piensa" que está libre de bugs..............

Mis comentarios personales:

No existe software perfecto, eso es un hecho, no hay código fuente perfecto, no existe la base de datos perfecta, ni el equipo de desarrollo perfecto, todos son personajes de ficción que viven en el mismo lugar donde vive Mickey Mouse o Pikachu, lo que si existe es el software, simple y llano.

El desarrollo de software es muy similar al proceso de manufactura de un producto, sigue el principio de GIGO (Garbage In, Garbage Out, entra basura, sale basura), cuando vamos a fabricar un producto, el tener buena materia prima, excelente maquinaria y mano de obra calificada garantiza la calidad del producto final, lo mismo en programación, buenas tecnicas de analisis, diseño de sistemas y bases de datos (UML, TopDown, CASE), un lenguaje de programación potente, un diseño armonico de la intefaz con el usuario, garantiza un producto de software de calidad, que si bien no estará libre de bugs, si será por lo menos utilizable.

Por otro lado, el proceso de prueba del software no es simplemente agarrar a las primeras personas que pasen por el pasillo de la oficina y sentarlos frente a la computadora a probar el software, de hecho, la empresa debe evitar probar ellos mismos el software que desarrollan, por 2 razones: primera, como dice Fuckowski, que "los hijos de uno nunca son feos", es decir, que tenemos una barrera mental la cual nos impide ver defectos en aquello que hemos desarrollado con tanto esfuerzo y 2do, porque siempre que nosotros mismos probamos las cosas que hacemos, simpre planeamos las pruebas bajo el supuesto de que nunca se encontrarán errores.

Nunca se debe utilizar gente de la empresa para probar el software propio, y menos pensar que entre menos se conoce el software por parte del encargado de probarlo, mejor realizará la labor de prueba, primero porque como personal de la empresa, existe la relación de trabajo entre tester / desarrollador, aunque no trabajen en el mismo departamento, y segundo porque el hecho de que el tester no conozca el programa, puede llevar a engañarnos a nosotros mismos con el pretexto por parte del tester de "los problemas vienen porque no se como utilizar el programa" y por parte del desarrollador que puede ocultar los bugs bajo la aparencia de "nuevas características".

Otro error muy común es cacarear el huevo antes de ponerlo, usualmente los desarrolladores nos creemos la octava maravilla del mundo mundial, nos comemos la mierda a puños y nadie desarrolla mas rapido y mejor que nosotros, lo cual nos lleva a decir barbaridades como .... en 3 meses tenemos el nuevo sistema en la calle y funcionando, recordemos siempre que el tiempo del programador no transcurre a la misma velocidad que para el resto de los mortales, ¿ cuantas veces le hemos pedido a un programador que nos haga un pequeño cambio en el programa, y cuantas veces hemos escuchado, "en un dia te lo tengo"?, pasan 3 semanas y el cambio nunca se realiza, y hasta la 4ta semana escucharemos..... "te acuerdas de lo que me pediste hace como un mes, pues ya esta hecho", con esta equivalencia, y calculando en "tiempo de programador" 3 meses, si "un dia" equivale a 4 semanas, luego entonces, 90 dias (3 meses) equivalen poco mas o menos a 360 semanas, si metemos 2 programadores al proyecto, entonces esta cantidad de tiempo debiera reducirse a la mitad, es decir, 180 semanas, añadir un tercer programador al proyecto, debiera reducirlo a 120 semanas, y un cuarto programador dejaria en 90 semanas el tiempo total. Siguiendo con esta regla, entonces para terminar el proyecto en los 90 dias cacareados, necesitariamos 40 programadores..... asi que recuerden esta regla, tanto si eres usuario como si eres programador.

Por otro lado, tenemos la presión del cliente, cuando prometas algo a tus clientes, no te queda mas remedio que cumplir, entonces, a ver si aprendemos a tener la boquita mas cerrada y no prometemos milagros de versiones maravillosas en tiempo record, porque eso NO EXISTE.

Si por presiones del cliente comenzamos a librerar un software que no ha sido bien probado, lo mas seguro es que vayamos a perder al cliente, al que nos presiona, y a otros tantos mas, porque lo que vamos a entregar va a ser una version llena de errores, que en el mejor de los casos operará a menos del 50% de su capacidad total, de paso le estamos abriendo la puerta de la empresa de nuestro cliente a nuestra competencia porque si nuestro programa no funciona de acuerdo a lo cacareado (olvidate de las especificaciones, si tu prometiste que el programa hace tal o cual cosa, debes cumplirlo, no importa que lo que prometiste no esté escrito en la "lista de especificaciones y nuevas características"), nuestro cliente evidentemente buscara otro programa que soluciones sus problemas.

Otra cosa que suele pasar, es que el desarrollador responsable cree una dependencia por parte de la empresa hacia su persona, de tal forma que el desarrollador responsable nunca puede irse de vacaciones, nunca puede tomarse un dia libre, o está sometido a horarios de 20 horas al dia, porque "alguien tiene que poder meterle mano al programa" cuando comiencen a saltar los errores.

Usualmente los programadores responsables terminan hartandose de la presión, renunciando o bien formando sus propias empresas (teniendo como socios a otros miembros de su mismo equipo de desarrollo) que incluso pueden ser competencia de nuestro propio producto (mucho ojo con los contratos de confidencialidad, asegurense cuando contraten un programador, de que firme un contrato de confidencialidad y competencia por lo menos durante 5 años posteriores a la fecha de que salga de la empresa, tambien asegurate de que el contrato especifique que todo el desarrollo realizado en durante su vida laboral en la empresa, para la empresa y en equipos de la empresa, es propiedad total y absoluta de la misma y no de desarrollador).

¿ Qué pasa si se marcha el programador responsable ?, pues que hay que meter a otra gente a solucionar los problemas, pero, como usualmente los responsables no son "muy comunicativos" que digamos en cuanto a las cosas que están haciendo, cosa que les garantiza el puesto en la empresa, nadie sabe lo que hicieron, ni aun sus mismo jefes, razon por la cual, reparar todas la fallas por parte de gente ajena, lleva a la creación de nuevas fallas derivadas de solucionar las fallas viejas y mas que nada por no contar con documentación tecnica del sistema.

Cuando un barco se hunde... ¿ quienes son los primeros en abandonar la nave ?.... pues la ratas, una vez que el producto final no cumpla espectativas, le estamos dando a la competencia nuevas armas, y mas tarde que temprano terminamos cerrando la cortina, o bien vendiendo la empresa.

Así pues, puede parecer que estos comentarios de Ross están hechos en broma, pero es cierto que hay mucha verdad detras de ellos.