Compartilhar via

¿Tiene lugar la belleza en el diseño de software?

  • Artigo

La belleza depende de quien mira, lo que puede ser bello para una persona también puede percibirse como horrendo para otra persona. Por eso es muy importante fijarse quien está percibiendo y qué es lo que está siendo observado. Una valoración acerca de jugar al golf hecha por Tiger Woods puede ser más aceptable que la misma hecha por Albert Einstein sin importar cuán bueno era este último en su campo de estudio.

Los consumidores de tecnología puede que no se interesen en los detalles del diseño interno de dicha tecnología en tanto que su interfaz operacional ofrezca una cierta ilusión de simplicidad y efectividad. Muchos —si no es que todos— los productos de alta tecnología se presentan como cajas negras. Para el caso de los consumidores de tecnología de software, el producto es el conjunto correspondiente de bits de código máquina ejecutable cargado o compilado al instante y localizado en memoria RAM en tiempo de ejecución —tal como es propuesto por Szyperski, Murer & Gruntz y otros— mientras que el código ejecutable en un almacenamiento persistente es la especificación para el ensamblaje de dicho producto. Esta especificación para ensamblaje es consumida por la fábrica de software de más bajo nivel en las actuales máquinas de cómputo automático del modelo de Turing: el cargador (o el componente IHostAssemblyManager del Common Languaje Runtime de Microsoft).

Así que, ¿Cuál es el rol de, digamos, el texto fuente escrito en la interfaz de usuario de Microsoft Visual C# (es decir, su sintaxis)? Respuesta: los planos de un producto de alta tecnología de software*; más específicamente, su especificación de diseño.

Por supuesto, los consumidores de software pueden no importarles los atributos de la especificación de diseño para la tecnología que consumen. Pero ¿Qué hay de los productores de dicha tecnología, aquellos que están preocupados no sólo de una ejecución sino de la evolución sostenible de una familia de complejas tecnologías en múltiples versiones? ¿Deben ellos cuidar la relación entre los atributos de sus especificaciones de diseño? ¿Debieran ellos cuidar aquella cualidad o combinación de cualidades que apelan a las facultades intelectuales o morales, por gracia inherente, o idoneidad a un fin deseado**?

He observado que la búsqueda por la belleza en el diseño de software —en la acepción arriba implicada— agrega valor más rápido de lo que agrega costos. Por lo que coincido con lo que menciona Joel Spolsky en su escrito Hitting the High Notes.

Como frecuentemente es el caso en las corporaciones, las respuestas a las preguntas anteriores son enteramente personales y no importa cuanta coerción o ilusión de control piensen los grupos directivos que tienen sobre los grupos de desarrollo, el efecto neto en la calidad de los productos de software permanece en las manos de quienes escriben, por ejemplo, texto fuente en la interfaz de usuario de Microsoft Visual C# (es decir, su sintaxis).

*Por favor nótese que las propiedades de los productos de software coinciden con muy, muy pocas propiedades de productos hechos de átomos y nombrarlos ‘productos’ en realidad es engañoso, como lo propone Armour y otros.

**Es decir: belleza tal y como es definida en el Oxford English Dicctionary

Comments