El otro dia, en una conversacion escuche el siguiente comentario: «generalmente conseguimos estimar bastante bien el tiempo de desarrollo, el problema es que despues aparacen algunos bugs que nos atrasan y es imposible estimar cuanto tiempo lleva corregirlos».
Esto no es critica a quien lo comento, ya que creo que es un razonamiento bastante comun, pero creo que no por eso debe ser aceptado.
No creo que se pueda escribir codigo totalmente perfecto y sin bugs, pero creo si que la industria del sw se ha vuelto demasiado tolerante al respecto. A mi entender lso bugs deben ser la excepcion y no la norma.
No recuerdo quien era, pero con Sergio en el Technion teniamos un companero que realmente no entendia porque la gente escribia codigo con bugs, para el era una perdida de tiempo….. y lo peor es que realmente nunca tenia bugs….. pero como ese hay muy pocos.
Pero como decia, creo que nos volvimos demasiado tolerantes, y con un poco de voluntad se podrian minimizar drasticamente.
No encontre datos (tampoco busque mucho), pero es sabido que el costo de corregir un bug sube exponencialmente segun la etapa en que se identifica: diseno, codificacion, compilacion, testing en R&D, test en QA, Beta, y mercado.
Parte del problema a mi entender es que hoy las herramientas son tan rapidas, que «teoricamente» es mas facil escribir rapido y mal y dejar que el compilador encuentre los errores que pensar y revisar acordemente. En mi epoca, y mas en un ambiente de embedded, las cosas no eran asi, una nueva compilacion podia llevar 5-10 minutos, un «make» entero 4-5 horas, quemar una nueva version en rom o cargarla en un emulador llevaba varios minutos, etc, por lo tanto era mucho mas eficiente (y divertido) programar bien y sin errores de entrada (no habia nada mas frustrante de perder 1 hora preparando una nueva version, para ver en 3 segundos que no funcionaba).
Creo que se puede y debe implementar en las empresas una politica de tolerancia cero a los bugs, y exigir reducirlos a un minimo. Yo tenia un companero de trabajo, Alex se llamaba, en realidad no era ingeniero en sw sino astrofisico reconvertido a sw, y era otro que no entendia el tema de los bugs, y peor aun, tomaba como una falta de respeto que alguien le entregara una version de codigo para integrar que no estuviera bien testeada, y de a poco iba poniendo a muchos en su lista negra, «yo con xxx no trabajo, escribe codigo con bugs y me hace perder tiempo», decia bastante seguido. Obviamente no era muy querido, pero la realidad era que cuando las papas quemaban y el proyecto era critico siempre lo terminaba haciendo el. Me lo termine llevando a Breezecom obviamente (y en nuestra primer version, estimamos el tiempo de desarrollo, incluyendo hw, sw, radio, y demas, en 18 meses, y liberamos la version con 1 mes de atraso, 3 meses despues liberamos una version nueva y no tuvimos que sacar ninguna version mas por 1 anio).
La prueba de que se puede escribir sw sin bugs es el VLSI design, no es mas que sw, pero como el ciclo de desarrollo es de mas de un anio, y el costo de 1 bug es de millones, se disena y testea de tal forma que los bugs son la excepcion y no la norma.
Si la industria del sw entendiera que el costo de ir retrasando una version por los consecutivos bugs, el dano de imagen que genera una version con errores, etc, a mi entender podriamos planificar correctamente los tiempos de desarrollo, posiblemente parezcan mas largos en el papel pero van a hacer mucho mas cortos y predecibles en la vida real.
Nuevamente, que nadie se sienta atacado personalmente con este email, es simplemente una reflexion sobre el estado de la industria.
Pablo Brenner & Sergio Fogel Blog 