El objetivo final

El objetivo final del software

¿Qué es lo que importa a la hora de hacer software? La pregunta, aunque aparentemente sencilla, tiene bastante más implicaciones de lo que se puede pensar a simple vista.

Tanto a nivel personal como colectivo, podemos encontrar diferentes respuestas que se dan a la pregunta.

La respuesta básica: Que funcione

Esta es la respuesta más inmediata y directa, quizá. El software debe funcionar.

Lo malo es que esta es una respuesta demasiado evidente. Es decir, realmente no aporta nada decir que debe funcionar. Saber que debe funcionar, no nos dice cómo conseguirlo, ni a qué factores debemos dar prioridad. Es más, es demasiado genérico y a la vez limitado. Funcionar, cumplir su función ahora no garantiza que la cumpla mañana o dentro de un mes. Tampoco indica en qué condiciones. Podemos hacer que el software "funcione" en unas ciertas condiciones pero que luego no sea posible reproducir ese funcionamiento en ninguna otra, y no parece razonable decir que esto sea aceptable.

Esto no quiere decir que la respuesta sea incorrecta. Por supuesto, es importante que el software funcione. Tanto que es innegable. Construimos una pieza de software para que tenga una función, y que sea capaz de cumplirla es un requisito indiscutible.

Lo que también es indiscutible es que esta respuesta no es suficiente.

El código perfecto

Más allá de ese indispensable "funcionar", surge entonces la idea de producir el mejor código posible, un código perfecto. Porque, quizá porque es lo que tenemos más a mano y más manejamos al programar, asumimos que la respuesta -lo que importa- es el código.

Y surge también entonces la necesidad de definir cómo podemos medir la perfección de ese código. Cómo saber si un código es mejor que otro. Cómo saber si un código es el mejor. Obviamente hay muchas opiniones y criterios.

Una primera idea es la de medir el código de alguna forma. Se hace seguimiento de los errores, se calculan cuántos errores se están encontrando por línea de código. También se pueden introducir tests en el desarrollo y entonces hacer más mediciones, como la cobertura -cuánto de nuestro código está "cubierto" por tests y cuánto no- o el número de tests por línea de código... Diferentes medidas más o menos objetivas. Y también, por qué no, se aplican "medidas" más subjetivas. Se aplican, por ejemplo, herramientas para mantener la uniformidad del código, o se definen algunas buenas prácticas básicas con el mismo objetivo de uniformidad, de que todo el equipo escriba un código con unas mismas pautas. Intervienen aquí bastante las preferencias personales de cada desarrollador y las experiencias que haya tenido -o no- probando diferentes cosas. Surgen, claro, muchas discusiones..

Todo esto sumado puede dar una idea del estado del código, de cómo es de fiable en general. Pero... Hay cuestiones aún pendientes de considerar. Por una parte, hemos hecho una asunción sin explicar demasiado bien el porqué. Lo que importa es el código, hemos dicho, pero no tenemos una certeza basada en poco más que una ocurrencia. Por otro lado, incluso aceptando eso, hay muchas cosas que esta calidad del código de la que hemos hablado no abarca. Por ejemplo, ¿de qué sirve un código elegante y cuidado si el resultado final es un programa que es demasiado complejo para el usuario, que no entiende o que requiere un esfuerzo innecesario por su parte? O también, ¿de qué sirve que el estado actual del código sea estupendo si es demasiado costoso de modificar o ampliar para servir nuevas necesidades? O ¿qué importa que el código sea bonito si es extremadamente lento?

Especializaciones de la optimización

El egoísmo acabará destruyendo la civilización. Es un sentimiento que se interpone en la colaboración e impide el progreso. Pero en alguna medida es casi inevitable. Es un sentimiento humano que también tiene sus elementos positivos, como por ejemplo el de proporcionarnos un instinto de supervivencia.

Dejando a un lado estos desvíos tan filosóficos, el egoísmo también interviene en situaciones como las de nuestros proyectos de software. Sobretodo cuando hay especializaciones. Diferentes grupos tienden a especializarse en diferentes intereses. Unos en el rendimiento, otros en la usabilidad, otros en el diseño de arquitecturas, otros en infraestructuras de ejecución, otros, por qué no, en los tiempos, en poder poner en producción cambios a la mayor velocidad posible. Y entonces todos y cada uno de estos grupos, naturalmente, defiende que lo suyo es lo importante. Que lo que realmente importa es, casualmente, esa parte a la que se dedican ellos.

Todos tienen algo de razón y, por tanto, ninguno de ellos la tiene. Porque sí, todos estos son aspectos importantes, pero ninguno de ellos tiene una justificación convincente para prevalecer siempre por encima de todos los demás.

WiP

Ingeniería: La Economía del Código