La importancia de la calidad en la programación de software según E.W.Dijkstra

Hola a todos,

Para los ingenieros de software tradicionales, el nombre de E.W.Dijkstra evoca una gran cantidad de respeto por la cantidad de trabajo realizado en el campo de la informática y la programación de software. Yo, siendo de la generación más joven, fui presentado a EWD (el nombre corto utilizado por el Sr. Dijkstra en todas sus publicaciones) a través de su artículo donde se consideraba perjudicial la declaración GOTO. Últimamente, la ponente Bodil Stokke me dejó sin palabras con nuevas revelaciones e ideas sobre las obras de EWD. Como reflexión posterior, intenté leer un par de sus artículos sobre programación de software: 'La tarea del programador considerada como un desafío intelectual' y 'Hacia programas correctos'. La declaración que más me impactó fue, según EWD, el procedimiento de aseguramiento de calidad o prueba seguido después de la fase de implementación es similar a poner el carro delante del caballo. En este blog, tengo la intención de profundizar más en esta declaración y algunas otras declaraciones de EWD relacionadas con la garantía de calidad a través de pruebas y depuración.

Todos estamos entrenados para creer en marcos probados y comprobados. Todos estamos educados con los pasos hacia el éxito y también tendemos a dedicarnos a esta corriente de pensamiento. EWD es conocido por proclamar obituarios escandalosos relacionados con la programación de software que con el tiempo se han demostrado ciertos. Por experiencia, he observado que el proceso de control de calidad nos ayuda a identificar los errores en la solución. Esto implica que los errores fueron introducidos en la solución por el programador, ya que el programador tiene el control total sobre la solución (a pesar de todas las quejas del programador de que está controlado por el cliente/gerente/colega/RRHH, etc.). Así que, introducimos el error y luego introducimos el paso para identificar los errores.

Avanzando, identificamos los errores y los registramos en el rastreador. Luego, el programador quema el aceite de medianoche o la electricidad de medianoche para convertir todos los casos de prueba de ROJO a VERDE. Luego, pasamos la solución como funcionando perfectamente y lista para usar al cliente. Si la fase de pruebas es para eliminar todos los errores, ¿por qué seguimos manteniendo la fase de soporte para rastrear los errores una vez en producción? EWD dice: "las pruebas de programas pueden usarse de manera muy efectiva para mostrar la presencia de errores, pero nunca para mostrar su ausencia". Las pruebas son una fase importante, pero le hemos dado demasiada relevancia para entregar una solución de calidad. Es una forma de calificar una solución pero no de garantizar una solución de calidad. La calidad es un pensamiento que debería ser invocado cuando comenzamos el proceso de diseño de la solución. Intentar insertarlo al final del proceso de entrega es un proceso de limpieza inútil. Es similar a la limpieza exterior de un nuevo edificio donde NO podemos hacer nada sobre la estructura interna.

EWD habla mucho sobre la importancia de comprender la estructura interna de las entidades abstractas. Nunca podremos generar y probar todos los casos de prueba posibles para una solución particular para determinar su completitud. EWD cree que tenemos que llegar a un proceso de deducción similar a las matemáticas donde demostramos fórmulas basadas en ciertos casos y si son válidas en esos casos, aseguramos que también funcionarán en otros casos. Bueno, es un pensamiento complejo y arriesgado recurrir totalmente a la forma anterior de proceso de solución. Tampoco sugiere que se abandone la prueba como procedimiento. Son herramientas/procesos necesarios en la programación de software. Pero, hemos observado una y otra vez que hemos intentado el viejo vino y deja el mismo sabor en la boca, agrio.

El programador debería pensar en las características necesarias de la solución de programación antes de la implementación y no como una idea posterior. Todos tendemos a pensar en los atributos del programa después de su implementación en lugar de incluirlos como parte de las especificaciones antes del desarrollo.

Una de las razones detrás de la profunda proliferación de estos terribles hábitos en la industria del software según EWD, es que la necesidad de satisfacer la creciente demanda de software se cumple llamando a más programadores, en lugar de a los más capaces, que podrían derivar su mayor capacidad de una mejor comprensión de la naturaleza de la tarea de programación.

Al mirar hacia atrás en mi carrera, es desconcertante ver que a pesar de todas las señales de advertencia dadas por los grandes ingenieros de software como EWD desde los años 60 y 70, todavía estamos atrapados en la misma antigua forma de desarrollar software de (no) calidad. Incluso ahora, recurrimos a los mismos pasos y acabamos con el mismo producto. Ágil o no-Ágil, necesitamos una sacudida importante en el proceso de pensamiento. También es responsabilidad de los programadores poner el pie en tierra y asumir la responsabilidad de garantizar la calidad. Si los programadores no están calificados/interesados en ello, entonces es responsabilidad del líder del equipo/gerentes empujarlos hacia ello. Finalmente, es responsabilidad de todos nosotros limpiar el desorden y poner las cosas en orden. Se ha convertido en algo así como la política, donde todos los que se meten en ella tratando de deshacerse de la corrupción terminan siendo corrompidos por el sistema. Como de costumbre, terminamos culp