http://spanish.joelonsoftware.com/PainlessSpecs/1.html
Por Joel Spolsky
Traducido por Miguel Cardo
Editado por Domingo Piña Maza
2 de octubre, 2000
Cuando El Test de Joel apareció, uno de los asuntos más espinosos denunciados por los lectores estaba relacionado con con escribir especificaciones. Parece que las especificaciones son como pasarse la seda dental: todo el mundo sabe que debería estar escribiéndolas, pero nadie lo hace.
¿Por qué no se escriben especificaciones? Dicen que porque saltándose la fase de escritura de especificaciones se ahorra tiempo. Se comportan como si la escritura de especificaciones fuese un lujo reservado a los ingenieros de lanzaderas de la NASA, o a los que trabajan para gigantescas compañías de seguros. Chorradas. Para empezar, dejar de escribir una especificación es el mayor riesgo a que uno se expone, sin necesidad, en un proyecto software. Es tan estúpido como lanzarse a recorrer el desierto del Mojave sólo con la ropa que uno lleva puesta por todo equipo, esperando “cruzarlo de un salto”. Aquellos programadores e informáticos que se sumergen en el código sin haber escrito una especificación tienden a pensar que son pistoleros de nervios de acero, pegando tiros desde la cintura. No lo son. Son tremendamente improductivos. Escriben mal código y producen un software mediocre, poniendo en peligro sus proyectos por exponerse a riesgos gigantescos, que nadie les había pedido.
Creo que, en cualquier proyecto no trivial (más de una semana de codificación o más de un programador), si no dispones de una especificación, gastarás más tiempo y crearás código de peor calidad. Aquí está el porqué.
La función más importante de una especificación es diseñar el programa. Incluso si eres el único trabajando en el código, y escribes una especificación solamente para tu propio beneficio, el acto de escribirla — describiendo minuciosamente cómo funciona el programa — te obligará a diseñarlo de verdad.
Visitemos a dos programadores imaginarios, en dos compañías. Juan Veloz, de Bananas Raudas Software, nunca escribe especificaciones. "¿Especificaciones? ¡No necesitamos esa mierda!". Al mismo tiempo, Mister Rogers, en La Compañía del Software Bien Temperado, se niega a escribir código hasta que la especificación haya sido concretada por completo (estos son solamente dos de mis muchos amigos imaginarios).
Juan Veloz y Mr. Rogers tienen algo en común: ambos están a cargo de la compatibilidad hacia atrás de la versión 2.0 de sus respectivos productos.
Juan Veloz decide que la mejor forma de proporcionar compatibilidad hacia atrás consiste en escribir un conversor, que simplemente convierte los archivos de la versión 1.0 en archivos de la versión 2.0. Se pone a machacarlo. Teclea, teclea y teclea. Clic-clac-clac. Los discos duros giran. Vuela el polvo. Al cabo de unas dos semanas, tiene un conversor decente. Pero sus clientes han quedado descontentos. El código de Juan Veloz obligará a todos los empleados de la compañía a actualizarse a la nueva versión. Su mayor cliente, Nanner Splits Unlimited, se niega a comprar el nuevo software. Nanner Splits necesita saber que la versión 2.0 todavía será capaz de funcionar con archivos de la versión 1.0 sin tener que convertirlos. Juan Veloz decide programar un conversor hacia atrás y enlazarlo a la función “guardar”. Es un poco caótico, porque, al usar una función de la versión 2.0, parece que funciona, hasta que te pones a guardar el archivo en formato 1.0. Sólo en ese momento se te dice que la función que estabas usando media hora antes no funciona en el formato antiguo. Así que escribir el conversor hacia atrás llevó otras dos semanas, y no funciona nada bien. Tiempo transcurrido, 4 semanas.
Ahora bien, Mr. Rogers, el de La Compañía del Software Bien Temperado, es uno de esos tipos repelentes de tan organizados, que se niega en redondo a escribir código hasta que no tiene una especificación. Dedica 20 minutos a diseñar la característica de compatibilidad hacia atrás de la misma forma que Juan Veloz, y nos sale con una especificación que básicamente dice:
La especificación se muestra al cliente, quien dice: "¡Espera un momento! ¡No queremos cambiar a todo el mundo a la vez!" Así que Mr. Rogers está otro rato pensando, y corrige la especificación para decir:
Han pasado otros 20 minutos.
El jefe de Mr. Rogers, un pirado de los objetos, lo mira y sospecha que algo podría ir mal. Sugiere una arquitectura distinta.
20 minutos más.
A Mr. Rogers no le hace ninguna gracia. Este rediseño llevará 3 semanas, ¡en lugar de las 2 semanas que estimó al principio! Pero resuelve todos los problemas del cliente, y de una forma elegante, así que se pone manos a la obra y lo hace.
Tiempo transcurrido para Mr. Rogers: 3 semanas y 1 hora, en total. Para Juan Veloz: 4 semanas, pero su código no es tan bueno.
La moraleja de la historia es que, con un ejemplo inventado, uno puede probar cualquier cosa. Uy. No, eso no es lo que quería decir. La moraleja de la historia es que, cuando diseñas tu producto en un lenguaje humano, sólo lleva unos minutos el tratar de pensar en varias posibilidades, revisar y mejorar tu diseño. Nadie se siente mal cuando borra un párrafo en un procesador de textos. Pero, cuando diseñas tu producto en un lenguaje de programación, lleva semanas hacer una iteración del diseño. Y lo que es peor, un programador que acaba de pasar 2 semanas escribiendo algo de código se va a sentir bastante identificado con ese código, da igual lo mal que esté. Nada que pudieran decir el jefe de Juan Veloz o sus clientes le convencería de tirar su precioso código conversor, incluso aunque no sea la mejor arquitectura. Como resultado, el producto final tiende a ser un compromiso entre el diseño inicial, incorrecto, y el diseño ideal. Era «el mejor diseño que podíamos conseguir, dado que ya habíamos escrito todo este código y no queríamos tirarlo.» No tan bueno como «el mejor diseño que pudimos conseguir y punto».
Así que esa es la razón principal número uno para escribir una especificación. La razón principal número dos es ahorrar tiempo de comunicación. Cuando escribes una especificación, sólo tienes que comunicar cómo se supone que funciona el programa una vez. Basta con que todos los del equipo lean la especificación. La gente de Calidad la lee, de forma que saben cómo se supone que funciona el programa y para qué tienen que hacer las pruebas. Los de marketing la usan para escribir sus vagas «hojas de características» para poner en la web, sobre productos que aún no han sido creados. Los de desarrollo de negocio la malinterpretan para destilar extrañas fantasías sobre cómo el producto curará la calvicie, las verrugas y demás, pero atrae inversores, así que está bien. Los desarrolladores la leen para saber qué código escribir. Los clientes la leen para asegurarse de que los desarrolladores están construyendo un producto por el que querrían pagar dinero. Los redactores técnicos la leen y escriben un bonito manual (que se pierde o se tira, pero eso es otra historia). Los jefes la leen de modo que pueden aparentar en las reuniones de jefes que saben de qué va la historia. Y así sucesivamente.
Cuando no tienes una especificación, toda esta comunicación sigue ocurriendo, porque tiene que haberla, pero es ad hoc. Los de Calidad juguetean un poco con el programa, y, cuando algo les parece extraño, van e interrumpen a los programadores una vez más para preguntarles otra estupidez sobre cómo se supone que funciona la cosa. Además del hecho de que esto arruina la productividad de los programadores, los programadores tienden a dar la respuesta que se corresponde con lo que escribieron en el código, en lugar de la “respuesta correcta”. Así que los de Calidad están en realidad probando el programa contra el programa en lugar de probar el programa contra el diseño, lo cual sería, ejem, un poco más útil.
Cuando no dispones de una especificación, lo que ocurre con los pobres redactores técnicos es lo más divertido (tristemente hablando). Normalmente, los redactores técnicos no tienen tanta influencia política como para poder interrumpir a los programadores. En muchas compañías, si los redactores técnicos caen en el hábito de interrumpir a los programadores para preguntarles cómo se supone que funciona algo, los programadores van a sus jefes y les lloran sobre cómo son incapaces de terminar nada por culpa de estos [calificativo borrado] redactores, y si podrían por favor mantenerles lejos, y los jefes, tratando de mejorar la productividad, prohíben a los redactores técnicos desperdiciar ni un segundo más del precioso tiempo de sus programadores. Es fácil saber de qué compañías se trata, pues los ficheros de ayuda y los manuales no te dan ninguna información que no puedas deducir de la pantalla. Cuando ves un mensaje en la pantalla que dice:
... y haces click en “Ayuda”, aparece un tema de ayuda tragicómico que dice algo como
Ejem, gracias. Aquí está bastante claro que el redactor técnico estaba tratando de ocultar el hecho de que no sabían qué es el soporte LRF-1914. No pudieron preguntar al programador, porque (a) les daba vergüenza, o (b) el programador está en Hyderabad y ellos en Londres, o (c) la dirección les ha prohibido interrumpir al programador, o cualquiera de otras patologías corporativas demasiado numerosas para mencionar aquí, pero el problema fundamental es que no había especificación.
La razón principal número tres para tener una especificación es que, sin una especificación detallada, es imposible hacer una planificación temporal. No tener un plan de tiempos está bien si se trata de tu tesis y esperas dedicarte a ella durante 14 años, o si eres un programador trabajando en el próximo Duke Nukem y lo distribuiremos cuando estemos listos. Pero, para casi cualquier clase de negocio real, simplemente tienes que saber cuánto tiempo van a llevar las cosas, porque desarrollar un producto cuesta dinero. Tú no comprarías un par de vaqueros sin saber cuál es el precio, así que ¿cómo va a decidir una empresa responsable si desarrolla un producto sin saber cuánto se va a tardar, y por tanto, cuánto costará? Para saber más sobre planificación temporal, lee Planificación Indolora de Proyectos de Software.
Un error tremendamente común es tener una discusión sobre cómo debería diseñarse algo, y no llegar nunca a una conclusión. Brian Valentine, el diseñador jefe de Windows 2000, era famoso por su lema «Las decisiones, en 10 minutos o menos, o la próxima es gratis».
En demasiadas organizaciones dedicadas a la programación, cada vez que se discute un diseño, jamás consigue nadie llegar a una decisión, normalmente por razones políticas. Por tanto, los programadores solamente trabajan en lo menos controvertido. Según va pasando el tiempo, todas las decisiones duras se dejan para el final. Estos son los proyectos que más probablemente fracasen. Si estás creando una nueva compañía basada en una tecnología nueva y notas que tu compañía es constitucionalmente incapaz de tomar decisiones, podrías perfectamente cerrarla ahora y devolver el dinero a los inversores, porque nunca distribuirás nada.
Escribir una especificación es un gran modo de fijar todas esas molestas decisiones de diseño, grandes y pequeñas, que quedan disimuladas si no tienes una especificación. Incluso las decisiones de poca entidad pueden quedar fijadas por una especificación. Por ejemplo, si estáis construyendo un sitio web en el que la gente se puede dar de alta, todos podéis estar de acuerdo en que, si un usuario pierde su contraseña, se la enviaréis por e-mail. Magnífico. Pero no es suficiente para escribir el código. Para escribir el código, necesitas saber las palabras precisas que irán en el e-mail. En la mayoría de las empresas, a los programadores no se les confían palabras que un usuario pudiera llegar a ver (y por buenas razones, la mayor parte de las veces). Por tanto, es probable que alguien de marketing o relaciones públicas o que haya estudiado filología sea requerido para que defina el texto preciso del mensaje. «Estimado Patoso, aquí está la contraseña que olvidó. Trate de ser menos descuidado en el futuro». Cuando te fuerzas a escribir una especificación buena y completa (y pronto hablaré mucho más sobre ello), te das cuenta de todas estas cosas y o bien las arreglas o bien las marcas con una buena señal roja.
Bien. Ya estamos en la misma página. Las especificaciones son la maternidad, o la paella de los domingos. Sospecho que la mayoría de la gente lo entiende, y mis sermones, siendo graciosos, no te están enseñando nada nuevo. Así que, ¿por qué la gente no escribe especificaciones? No es para ahorrar tiempo, porque no lo ahorra, y creo que la mayoría de los programadores lo reconoce. (En la mayoría de las organizaciones, las únicas “especificaciones” que existen son cortísimas, una página de texto que un programador escribió en el Bloc de Notas después de escribir el código y después de explicar la maldita función a la persona número 300).
Creo que la razón es porque a mucha gente no le gusta escribir. Mirar una pantalla en blanco es algo horriblemente frustrante. Personalmente, superé mi miedo a escribir apuntándome a una asignatura en la universidad en la que había que presentar un ensayo de 3 a 5 páginas una vez por semana. La escritura es un músculo. Cuanto más escribes, más eres capaz de escribir. Si necesitas escribir especificaciones y no eres capaz, empieza un diario, crea un weblog, apúntate a una clase de escritura creativa, o simplemente escribe una bonita carta a cada uno de los parientes y compañeros de habitación que dejaste escapar en los últimos 4 años. Cualquier cosa que tenga que ver con colocar palabras sobre papel mejorará tu habilidad de escritura de especificaciones. Si eres un jefe de desarrollo de software y la gente que se supone debería estar escribiendo especificaciones no lo hace, envíalos a uno de esos seminarios de escritura creativa de dos semanas en la montaña.
Si nunca has trabajado en una compañía que haga especificaciones funcionales, puede que nunca hayas visto una. En la próxima parte de esta serie, te mostraré una breve especificación de ejemplo para que lo compruebes, y hablaremos de lo que una buena especificación necesita tener.