Ingenieros, escojamos las palabras

Un proyecto de ingeniería, trate de lo que trate, es antes que nada eso, un proyecto. Nunca suficientemente valorado, este documento responde al qué, el cómo, el por qué, cuanto y quien realizará cada paso para llevar a cabo ese fin.
Quizá esté exagerando en eso de "nunca suficientemente valorado", excepto en el campo de la ingeniería del software, ese mundo lleno de vaguedades donde un prototipo es capaz de alcanzar el mercado a base de parches.

El caso es que leyendo este documento sobre XMPP me he fijado en la nota sobre el uso del lenguaje que se hace dentro del mismo documento. Viene a ser lo mismo que me explicó en clase el Sr. Castejón Limas, una de las pocas personas que hasta ahora he visto tomarse de verdad en serio un proyecto. Mis saludos desde aquí.

Uno de los pasos más importantes en cualquier proyecto es levantar correctamente las especificaciones; es decir ¿qué tenemos que cumplir para alcanzar nuestra meta?
Aquí entra en juego seriamente el lenguaje. No se trata de hacer una mera exposición de objetivos, sino en qué grado son importantes para el fin último.

Intentaré traducir brevemente el RFC 2119:

1. Debe: esta palabra junto con "tiene que" o "requiere" indica un requisito absoluto. Piensa antes de escribirlas porque TENDRÁS que cumplirlas.
2. No debe: indica una prohibición absoluta.
3. Debería: esta palabra junto con el adjetivo "recomendado" indican la posible existencia de razones válidas en circunstancias particulares para ignorar este ítem. Las implicaciones deben ser comprendidas y valoradas cuidadosamente antes de elegir un rumbo diferente.
   
4. No debería: esta locución, junto con "no recomendado" significa que puede haber razones válidas en circunstancias particulares en las que un comportamiento específico sea aceptable o incluso útil. Igualmente hay que comprender las implicaciones que esto conlleva y pensárselo bien antes de implementar algo etiquetado de esta manera.
   
5. Puede: al igual que el adjetivo "opcional" significa que un ítem es completamente opcional.
6. Imperativos: Deben ser utilizados únicamente cuando sea realmente necesario para interoperabilidad o para evitar daños. No deben, por ejemplo, usarse para imponer un método o implementación si no es necesario para interoperabilidad.
7. Consideraciones de seguridad: el autor del documento debe tomarse el tiempo necesario para mostrar las implicaciones de no seguir las recomendaciones y requisitos, ya que los efectos pueden ser inicialmente sutiles y que el implementador probablemente no tenga la experiencia del que escribe la especificación (que por algo la escribe).

Estos son, aproximadamente, los términos en que se expresa el citado RFC.

En resumidas cuentas: hay que pensar lo que se escribe en un proyecto, ya que luego hay que hacer lo que se ha escrito.