Linked

Desde que el mundo es mundo existe la discusión sobre si la informática es una ingeniería o no, sobre si el ciclo de vida de un proyecto debe ser así o asá, incluso desde hace un tiempo se habla (y se discute) sobre si el código fuente es el diseño o no. Incluso aquí hemos discutido sobre puentes que se prueban con camiones. Me llama mucho la atención la tendencia de muchas empresas a industrializar el mundo del desarrollo en base a factorías de software y herramientas varias, basadas en analogías incompletas.

Y no es que el objetivo no sea completamente legítimo teniendo en cuenta nuestro porcentaje de éxitos en los proyectos informáticos, simplemente parece que demasiadas veces no se entiende esta profesión. El 80% (apreciación personal, si el lector quiere cambiar el número, que lo cambie) de los documentos que se escriben en un proyecto no se leen jamás en detalle y, lo que es peor, los que se leen normalmente no se actualizan a lo largo de la vida del proyecto. Yo no voy a pedir que no se escriba documentación, pero quizás no lo estemos haciendo de la forma adecuada, o quizás el ámbito de actuación de ese deseo de industrialización sea escaso, limitándose a la parte de construcción/programación.

No quiero decir que el cliente tenga que aprender a programar, pero decidme si no tendría sentido un escenario dónde las “pruebas” se escribieran directamente de una forma técnica (es decir, que se puedan instrumentalizar directamente). ¿No debería un analista funcional escribir un test de integración en la herramienta de pruebas definida para tal uso, de la misma manera en la que en los proyectos de ingeniería se utiliza directamente el Autocad desde el diseño hasta probar cosas?. ¿No ganaríamos todos con ello?. Por una parte se estaría haciendo un diseño de interfaces (interfaces de programación/apis) con sentido para el negocio (notar la palabra “diseño” de “diseño de interfaces”), por otra el analista tendría claro que lo que él ha escrito es lo que se está probando, y lo que es más, podría automatizar esa prueba (una vez se haya desarrollado).

Esto tampoco es nuevo, es lo que siempre se ha llamado Test Driven Development y que ha recibido recientemente nuevas vueltas de tuerca como el Behaviour Driven Development, pero es algo fundamental en el mundo de factorías y subcontratación que tenemos (o quieren que tengamos) hoy en dia, dónde cada vez hay más niveles y más problemas para transmitir la información entre ellos (¿hace falta el experimento de pasar un mensaje al oído del compañero y ver como acaba?).

Sin embargo lo que vivimos es lo contrario. Herramientas milagrosas cuyo resultado siempre hay que retocar y toneladas (bueno, entre 0 y N) de documentación que nadie lee ni actualiza. ¿Por qué?. Porque programar lo puede hacer un mono o porque, como he oído últimamente, se trata de describir todo para que al programador no le quede lugar a la interpretación. Es discutible si somos capaces de describir todo -o incluso algo- de una forma coherente, pero aún así estaríamos queriendo traducir el lenguaje natural, impreciso y arbitrario, en un lenguaje técnico (el código fuente), teniendo ademas en cuenta que esto se produce en situaciones que habitualmente conllevan una importante carga de estrés (con poco tiempo para nada, y menos para leer y escribir con detalle ni hacer pruebas).

En una ingeniería cada nivel es capaz de entender el material técnico al detalle que se les pide. Tanto el cliente, como los ingenieros que lo diseñan, como la gente que está al pie de la máquina son capaces de mantener el flujo de la información técnica, por mucho que acaben cargando el puente con camiones. Sin embargo parece que los informáticos queremos ser más listos, llegando incluso a pasarnos de listos a la luz del pírrico porcentaje de éxito de nuestros proyectos.

Y este ejemplo aplicado a las pruebas es aplicable a muchas más cosas. Interface de usuario, listado de funcionalidad, etc. Ya hemos tratado este tema en el pasado también de una forma u otra (por ejemplo: la interface es lo primero). Renunciamos al prototipo (esqueleto vacío) como herramienta de discusión porque preferimos copia y pegar de una oferta que gastar unas horas en entendernos realmente con el cliente.

Obviamente en esta profesión hay sitio para todos y ni pretendo hacer un alegato para alzar a los geeks al poder ni menospreciar todo lo que no sea programación. Simplemente tenemos que encontrar un lenguaje común que minimice los problemas de interpretación. Y si en algo podemos estar de acuerdo es que el lenguaje natural y las toneladas de documentos escritos en él no pueden ser nuestra lingua franca.

Share This