Tolerancia
Hace tiempo que le doy vueltas a la idea de que el software en general tiene tantos bugs porque no se paga suficiente por ello. Es decir, un neurocirujano comete un error y el paciente muere. Un ingeniero comete un error y se cae un puente.
Sin embargo parece que estamos más que acostumbrados a los errores de software. Normalmente porque sólo generan algunas molestias, pero lo cierto es que cada vez hay menos cosas que no estén controladas por ordenadores, incluídas tareas críticas en las que un error puede significar pérdidas de miles de millones y vidas humanas.
Ahora pongámonos en el caso extremo. Supongamos que un fallo de software supusiera por ley la muerte del programador. Responsabilidad extrema. Se iban a acabar las alphas, las betas, y todo lo que no fuera software perfectamente probado y reprobado en todas las condiciones posibles. El número de bugs bajaría a casi 0. Pero claro, seguramente el número de programadores también bajaría mucho porque ¿quién quiere jugarse la vida en su trabajo? La parte buena sería que, al bajar la oferta de programadores, los sueldos subirían a la misma velocidad que la demanda. Se acabaron los picadores mileuristas y se nos consideraría poco menos que deportistas extremos, seguro que vendría Red Bull a patrocinarnos, tendríamos cláusula de rescisión y el PC World desbancaría al Marca en la lista de publicaciones más vendidas.
Y después de la tontería, el pensamiento profundo: parece que para que haya abundancia de picadores de software, las responsabilidades por lo errores tienen que ser bajas. Ummmm…. ¿De verdad es esto así? Desde luego es completamente cierto que hay mucho movimiento dedicado a mejorar la calidad del software: gestión de proyectos, control de versiones, unit testing, departamentos de calidad, validadores…. Pero tampoco es menos cierto que hay aplicaciones críticas que fallan. Y mucho.
Y cuando estaba escribiendo este post, me encuentro en VivaLinux con Red Hat Enterprise Linux 5, si lo hacemos, lo soportamos. Red Hat viene a decir, por escrito, sin letra pequeña y en sólo una página que su soporte abarca instalación, uso del producto, configuración, diagnóstico, y corrección de errores. ¿No estamos demasiado acostumbrados a aceptar sin pestañear en un click que el software que instalamos -libre o no- no se hace responsable de los daños que pueda causar?
[ACTUALIZACION]
Cómo estará la cosa, que la Free Software Foundation y Kriptópolis dicen que votar debería hacerse en papel:
Fíjense, sin embargo, en que votar es un caso muy especial. Sólo porque el software dentro de un ordenador sea libre no significa que se pueda confiar en el ordenador para votar. Nosotros creemos que no se puede confiar en los ordenadores para votar. Votar debería hacerse en papel.
Madre cómo estamos…
[/ACTUALIZACION]
July 2nd, 2007 at 7:37 am
En ese hiptético escenario de “Extreme Extreme Programing” (me río yo de http://www.extremeprogramming.org/) yo creo que habría series de televisión de programadores (en plan CSI, House, Lou Grant, etc) donde un grupo de programadores solteros y promiscuos se debaten día a día en el peligroso mundo de de la programción.
Aunque la verdad es que yo mas de un día me da la sensación de estar haciendo el papel de House: “Si no es lupus va ser el scope”.
ElSuricatoRojo
July 2nd, 2007 at 12:04 pm
Como ya sabes, en algunas ocasiones es culpa de la propia empresa por no tener a su disposicion gente que pueda testear a fondo todo el software, y los programadores no pueden estar a todo, sobre todo en epocas con demasiado trabajo. Asi que muchas veces el software sale sin estar 100% comprobado.
July 2nd, 2007 at 2:59 pm
Desde que comencé mi vida como programador he oscilado entre las posiciones de La Factoría y del Artesano Digital, entre la informática como ingeniería o la informática como artesanía. Creo, que últimamente estoy más cerca del artesano. Los motivos:
El cliente no sabe lo que quiere, al menos al 100%, y probablemente cambie de opinión varias veces a los largo del proyecto
Un prototipo no es lo mismo que el resultado final en pequeñito
Se puede hacer la misma cosa de maneras muy diferentes y no siempre igual de buenas
El software siempre tiene errores y siempre los tendrá
La ingeniería no tiene en cuenta el aspecto humano del desarrollador
El desarrollo de software es incremental, es decir, se construye sobre software ya desarrollado por terceros sobre los que no tienes control (y encima corre sobre máquinas que ni conoces)
Los entornos de desarrollo, pruebas y producción raramente son iguales
En definitiva, todo esto no quita para que se establezcan los controles necesarios, especialmente si son aplicaciones críticas. No puedes asegurar tu software al 100%, pero puedes dar soporte para cuando sucedan. Si el que sucedan es crítico, hay que diseñarlos en consecuencia, por ejemplo con redundancia a fallos, replicación de sistemas, etc. Existen amplias soluciones.