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 
Sí, es muy cierto.
Cabe diferenciar a lo que llamamos error.
Una «falta» del analista, diseñador, implementador puede generar un «error» ya sea en la satisfacción de los requerimientos,arquitectura o errores en ejecución respectivamente.
Es importante más que cuidar lor errores de implementación (memory leak, border cases, etc) los del análisis y diseño.
Cualquier error en estas etapas en efecto podría ocasionar una reingeniería del sistema.
Y por supuesto realizar una correcta implementación.
Pero como bien Pablo debes saber, en cualquier mercado e industria en especial en empresas p/m, la calidad es proporcional al tiempo de desarrollo -estoy sacando de la ecuación decenas de items, pero igual se cumple en la mayoría de los casos-.
Se habilita mi pago cuando entrego el beta en la fecha X. Estoy con problemas de liquidez. Se que la beta tiene algunos bugs ¿Qué hago?
La respuesta es clara. Estoy asumiendo claro, la responsabilidad moral en que todos estos errores se arreglan lo antes posible.
Sin embargo existen técnicas de implementación al «viejo estilo», entre ellas aparece PSP. Requeridas en algunas empresas como conocimiento básico. Estás aseguran un nivel de calidad superior y rentable respecto a la inversión de tiempo/stress ;-].
Pero como siempre digo y estoy de acuerdo contigo, es to es una INVERSIÓN.
Todo en la vida, cada acción puede ser tomada como una inversión y la mayoría de las veces si nos esforzamos al principio la inversión tiene sin duda alguna un resultado extremadamente positivo en el futuro cercano, mediano o a largo plazo.
La palabra mágica : Inversión.
Todo depende de quien sea tu cliente, el destinatario de ese software. Si lo que se está implementando es algo muy específico para alguna industria (automatización, análisis estadístico, etc) que puede valer mucho dinero, un bug puede ser algo bastante malo. En cambio, cuando el cliente es un usuario de nivel medio bajo (un sistema operativo o suite de oficina de propósito general), los bugs son algo mucho más tolerado. Personalmente conozco gente que me ha dicho que su Windows no le da ningún problema, que cuando se pone la pantalla azul lo reinicia y sigue andando. Evidentemente, ¿se va a preocupar Ms de eliminar todos los bugs?
Creo que la preocupación de los desarrolladores en programar bugs es directamente proporcional a la capacidad del usuario de poder identificar un determinado evento como un bug. Sin perjuicio de que haya mucho desprolijo programando por ahi debido a la escasez de gente formada adecuadamente.
Perdonen muchachos pero no estoy de acuerdo, justamente mi punto es:
Un programador profesional tiene que aspirar a escribir codigo sin bugs, independientemente de si su cliente lo va a tolerar o no. Despues es decision del CEO o Gerente de ventas si saca al mercado un producto con bugs o no. Eso si es una decision comercial.
Un programador bueno no deberia tomar los bugs con ligereza, entregar un codigo mal revisado, con bugs evitables, a un companero de trabajo, ya sea otro programador o la gente de testing es como decia mi amigo Alex una falta de respeto al otro.
Es cierto que hay imponderables, hay cosas que son muy dificiles de predecir, y de testear, pero en mis mas de 20 anios en la industria creo que mas de un 90% de los bugs que vi en mi vida eran «totalmente evitables» sin necesidad de invertir mas de un 10-20% de tiempo al que se invirtio en codificar.
En breezecom resumiamos los valores de la empresa en 2: «Excelence & Fun»
Ligereza en los bugs va justamente contra ambos, obviamente no es excelencia, y genera tensiones entre la gente que estropeaban el fun…
Tratar de escribir un programa sin bugs es como tratar escribir sin faltas de ortografía o errores de tipeo, pero más difícil. Las faltas de ortografía o errores de tipeo son perfectamente evitables, pero surgen en todo lo que escribimos. Por ejemplo, en este post Pablo puso «lso bugs» en el 3º párrafo. ¿Podría haberlo evitado? Sí. Entonces, ¿por qué lo hizo? Porque se equivoco como cualquier ser humano. ¿Qué se puede hacer al respecto? Releer el post buscando errores de ortografía y sacar una nueva versión con la corrección.
En la programación, además de los errores de sintáxis que los detecta un compilador (el análogo a los errores de ortografía o tipeo y un corrector ortográfico), están los errores de lógica, que se detectan cuando algo sale mal en el programa (testing).
Que es más beneficioso evitar los bugs que corregirlos no hay duda. ¿Es posible? No lo creo.
Saludos.
Existen metodologías para evitar los bugs en todas las etapas del desarrollo de un producto, el problema es que son muy costosas. Ahí es donde entra la apreciación que se haga de la relación costo-beneficio y como consecuencia de esto la tolerancia que habrá hacia los bugs.
Otro tema son las softwarehouses que te enchufan cualquier basofia y a precio de oro, esas empresas se abusan de los usuarios, en la mayoría de los casos esos abusos terminan yendo en contra de la empresa por la vía de la mala publicidad.
Escribir software sin bugs es imposible.
Hay algunos bugs que »saltan» en el lugar de la aplicacion y no el laboratorio.
Es necesario, el uso de »buenas» tecnicas de programacion para encontrar esos bugs mucho mas rapido, sumado a la experiencia que uno tenga !!
En mi caso realizo programas embedded en assembler, con micro-controladores, utilizando las tecnicas que aprehendi del creador del Pascal, Nicklaus Wirth, y de estudiar programas de PC (por no decir hackear) creados por distintos lenguajes de programacion, y gracias a ello he podido resolver los problemas que hoy se me plantean mas rapido !!??
Por otro lado, hay gente que vive de los bugs !!
Sino preguntenle a los empleados-creadores de algunos sistemas operativos !!
Saludos… y muy bueno el blog.
Antes que nada, felicitaciones a Pablo y a Sergio por el blog. Leo muchos blogs, pocos en español y este es el único que leo que es Uruguayo. Sinceramente, lo que escriben es interesante y diferente, con un punto de vista business y no populista o para hacer propaganda; que dificil es encontrar algo así online de producción Uruguaya.
Es imposible programar sin bugs, es posible minimizarlos, detectarlos y corregirlos antes de que el programa salga a producción, para eso existe SQA. Ahora la pregunta sería porque casi todas las empresas no tienen un departamento de SQA… y la respuesta es costo. Ojo, esto no tiene por que estar mal. Al final y al cabo es un negocio, nada mas.
Por otro lado, es bueno tender hacia una utopía de cero bugs cuando el código sale por primera vez de manos del desarrollador, porque apunta a aumentar la calidad y define un camino donde crecer en esta materia, pero es como tender a generar energía a un costo cero: puedes minimizar el costo, mas nunca llegar al costo cero.
Bueno, yo entiendo que la discusión que plantea Pablo no es si es posible o no tener una aplicación 0 bugs lo cual podría ser posible pero quizás muy caro o muy lento. Lo que yo entiendo y comparto es que hoy se está perdiendo la conciencia o nos estemos acostumbrando a que quiñes programan soft, acepten los bugs como normales y que es un problema de QA detectarlos. Yo creo que todos y no solo en software, debemos aspirar a hacer nuestro trabajo LO MEJOR POSIBLE de primera y no ver esto como un extra, si no como la norma, sin que esto tenga que ver con cuanto paga el cliente o si tengo o no todos los recursos. Pasa por respetarnos a nosotros mismos y a los demás y siempre hacer lo mejor posible en la tarea que sea.
Esto me recuerda a varias cosas que estoy leyendo en el libro Cradle-to-Cradle (que recomiendo).
Ahí se plantea que la contaminación puede evitarse by-design (el libro está impreso en un «papel» prototipo que no usa árboles en el proceso y puede re-imprimirse infinitamente). Básicamente lo que hacen es describir el proceso histórico por el cual terminamos intentando de reducir/minimizar/postergar los efectos contaminantes en vez de simplemente no generarlos. Según los autores, el motivo de fondo es la evolución que ha seguido la revolución industrial, dónde el problema a resolver siempre fue otro (como producir más autos con menos gente, etc).
Acá puede estar pasando lo mismo.. o sea, las metodologías de desarrollo de software que usamos fueron pensadas para resolver el problema más importante de la industria: que los proyectos no se terminan. Entonces, se generaron metodologías iterativas, herramientas que pasan de prototipo a producción rápidamente, etc para mantener ese riesgo bajo. Claro que, si se libera una vez por semana, o diariamente, es imposible liberar productos sin bugs… O sea, es by-design. Sin ese enfoque Google nunca hubiese existido. Claro que eso no habilita a liberar cualquier cosa, se deben usar mètodos orientados a testing (TDD, BDD, automatizar test de regresión, etc), pero al fin y al cabo, es lo mismo que con la revolución industrial, lo mejor que vamos a poder hacer con este enfoque es reducir los bugs (nada, poco, mucho o muchísimo), pero nunca eliminarlos hasta cero.
Ojo, otra cosa es la definición de bug, que es bastante subjetiva. En la empresa que trabajo actualemente un problema de usabilidad es un bug MUY serio. Si esto hubiese sido siempre así, casi toda la historia del software sería un bug gigante 🙂