Intencionalidad en el desarrollo de software

La intencionalidad en el contexto del desarrollo de software puede significar muchas cosas. Deseos. Ideas. Motivaciones. Planes. Análisis. Las cuales desembocan en ser, ante todo, conscientes de nuestras decisiones. Así, si debemos implementar un software Z, conlleva, una intención X. Que deberán realizarla los desarrolladores (cada uno con una intención). Con ello dejamos fuera cualquier acto deliberado que no cumpla con Z, pues no sería una intención, esto es, ser consciente que haces mal tu trabajo, por ejemplo, añadiendo código que no cumple con Z.

Un acto de sabotaje, siguiendo el ejemplo anterior, no es intencional porque va en contra de Z. De esta forma, una intención X para un software Z, consiste en una decisión honesta con Z, que busca cumplir sus requisitos. No obstante, y esto lo veremos a continuación, insuficiente para asegurar que la intención X pueda cumplir con el software Z.

Nunca ha sido fácil implementar un código que cumpla los requisitos. Requiere de una intención por parte del desarrollador. Y aunque esta persona puede tener todas las intenciones de cumplir el objetivo con su código, hay al menos dos motivos para incumplirlo:

1. Incapacidad de ejecución técnica. Las decisiones para cumplir Z son incorrectas por una mala ejecución del desarrollador, que puede implicar: (1) usar mal una herramienta; o (2) una decisión apresurada al momento de escoger una herramienta. No obstante, la incapacidad técnica no sólo consiste en una impericia para traducir un requisito en un código que lo cumpla, también, en una sobreimplementación, innecesaria, a la hora de emplear técnicas o herramientas que aplican una abstracción excesiva. Provocando, en cualquier caso, más que una solución, un nuevo problema. Por ello, la elección de herramientas y métodos de implementación debería ser algo a meditar.

2. Incapacidad de comprensión. Hay una brecha entre lo que dice el requisito y lo que entiende el desarrollador. Si, presuponemos, que hay una relación entre X y Z, en realidad habría una relación X con Y (donde Y sería distinto a Z porque el desarrollador entendió otra cosa). Provocaría, así, una falta de intención, no deliberada, como el caso un sabotaje, sino indirecta, pues el desarrollador creía que cumplía con Z.

Note que dejo fuera «Requisitos incompletos» porque según la definición inicial, incluso si falta información, no implica una ausencia de intención. Existe, como podemos suponer, una intención para el software, aun cuando su cumpliendo esté mal formulado.

Otra cuestión sobre la intención es que las personas deben estar involucradas. Esto, a pesar de ser evidente, conviene aclararlo. Una intención X para un software Z no puede hacer que su éxito (o su ausencia de éxito) recaiga en una metodología, técnica, teoría, herramienta. Es, pues, una cuestión que involucra al desarrollador, y es más, a todos los desarrolladores (cada uno con una intención) que buscan cumplir Z.

El problema surge cuando esa intencionalidad, que pueden ser múltiples para el cumplimiento de Z, no están en sintonía. Y guardan para sí mismas una falta de mecanismos de evaluación que, a su vez, impiden la reproductibilidad.