See discussions, stats, and author profiles for this publication at: https://www.researchgate.

net/publication/341549001

Si no está roto, no lo arregles. Comentario sobre "Especificación en

programación: Semántica y Flexibilidad"

Preprint · June 2019

DOI: 10.13140/RG.2.2.17367.91048

CITATIONS READS

0 1,301

1 author:

Julián Reynoso
National University of Cordoba, Argentina
4 PUBLICATIONS 0 CITATIONS

SEE PROFILE

All content following this page was uploaded by Julián Reynoso on 21 May 2020.

The user has requested enhancement of the downloaded file.

 Si no está roto, no lo arregles
Comentario sobre Especificación en programación: Semántica y Flexibilidad de
Xavier Huvelle

Julián Reynoso*

Junio 2019**

La expresión ((castillo de naipes)) aplica perfectamente a la manera en la que funcionan

los sistemas informáticos. Gran parte de nuestro sistema financiero (y bancario) corre en sistemas
antiquı́simos, con software que quizás pertenezca más a un museo que a los cajeros automáticos.
Una expresión utilizada muy frecuentemente en cı́rculos de computación es ((if it ain’t broken, don’t
fix it”))1 .

La tesis de Huvelle apunta a criticar la noción de especificación que Turner (2018) define
para el campo de la programación. Sostiene que no es suficiente para capturar muchas de las di-
ficultades con la que se encuentran quienes desarrollan programas para distintos tipos de sistemas
informáticos. El diagnóstico que realiza es que la noción de especificación es muy restrictiva en dos
aspectos. En primer lugar, se encuentran problemas a la hora de lidiar con la semántica de las espe-
cificaciones; en segundo con su flexibilidad. Resulta muy interesante estudiar el proceso de escritura
de software desde una persepectiva análoga a la de estudio de prácticas cientı́ficas, por lo que la
noción de resolución de problemas que propone el autor es un punto de partida muy prometedor.

Tal como se ha dicho ya, las especificaciones son aquello que define qué es lo que debe hacer
el sistema en cuestión. En este caso puntual, se habla de software, pero podrı́a ser un dispositivo de
otras caracterı́sticas. Un problema no menor con las especificaciones es que existe una variedad muy
amplia de roles que pueden cumplir durante el proceso: desde pasos muy concretos que deben seguirse
hasta ser tomadas como una especie de ideal regulativo al que se tiende, pero no necesariamente
se alcanza. El proceso de confección suele comenzar con el cliente2 , quien detalla lo mejor posible
* Facultad de Filosofı́a y Humanidades - CIFFyH. UNC
** Trabajo presentado en las 1ras Jornadas de Jóvenes Investigadores, FFyH - UNC
1 Si no está roto, no lo arregles.
2 Utilizo aquı́ ((cliente)) para seguir la nomenclatura de los autores, pero bien podrı́a tratarse de una misma persona

1
pre-print No apto para citar

qué es lo que pretende que el sistema en cuestión haga y los desarrolladores intentan lograr los
resultados deseados balanceando una cantidad no trivial de factores que el cliente puede no conocer:
qué tecnologı́a existe, cuales son los requerimientos técnicos para ejecutar esas tareas y qué recursos
existen a disposición.

En este sentido, la pregunta sobre qué tanto influyen estas especificaciones en las decisiones
que deben tomar quienes realizan el desarrollo no es trivial. El cliente puede esperar tareas que el
sistema puede desarrollar, pero en una escala temporal que le resulta inaceptable. O bien puede
requerir una capacidad de cómputo que no esté disponible en la implementación deseada3 .

Este problema se hace aún más relevante cuando el sistema en cuestión ha sido escalado
y heredado de veriones anteriores. Como bien ilustran los ejemplos de los bugs del Y2K y poten-
cialmente el Y2038, por restricciones ajenas a cuestiones meramente teóricas, resultó en una especie
de ((error de arrastre)) que tuvo más que ver con el hardware disponible en la época que con una
elección enteramente voluntaria.

Estos ejemplos ilustran que las especificaciones ideales para un sistema ponen en jaque
constantemente las implementaciones posibles al existir un número de variables que no son fácilmente
modificables para quienes desarrollan sistemas. Por lo tanto, la ejecución propiamente dicha del
sistema en cuestión es el resultado de un proceso constante de balancear las expectativas del cliente,
los recursos disponibles, y además, del conjunto de prácticas, la cultura (y prácticas) establecida en
la comunidad y la tiranı́a de los plazos y vencimientos.

Es por ello que la noción de flexibilidad que está presente en el trabajo es relevante, pero no
sólo para el código del programa que está siendo desarrollado sino también para la propia noción de
especificación. Encarar la escritura de software como un proceso de resolución de problemas, con un
conjunto de especificaciones que permita maleabilidad en la manera en la que se pretende alcanzar
la meta que el programa debe cumplir, es una via que parece más fructı́fera.

Quienes trabajan con el método Agile4 de desarrollo de software solicitan a los clientes que
narren una especie de historia, un cuento para que expliquen qué es lo que pretenden que el software
haga como primer insumo. Le llaman user stories o use cases, que funcionará después como base
para que el equipo de desarrollo confeccione el documento técnico que nuclee las especificaciones.
desarrollando una aplicación para uso personal y privado.
3 El cliente puede tener en mente que el programa sea ejecutado en un teléfono celular, pero quizás sea necesario

algo más poderoso.

4 Agile comenzó como una metodologı́a opuesta al llamado modelo de cascada. Una de la principales diferencias

consiste en que la fases de prueba y de compilación están más ligdas, con un bucle de retroalimentación más inmediato.
En el método de cascada, tradicional, una fase sigue a la otra solo después de que se ha completado.

2
 pre-print No apto para citar

A modo de cierre, me parece imporante recalcar que aún los programas que para el usua-
rio parezcan relativamente sencillos, esconden por detrás una complejidad que no es trivial5 . La
utilización de librerı́as (una serie de recursos a disposición de los programas que pueden ser desde
bloques de código pre-armados hasta datos de configuración o incluso sub-rutinas) es una práctica
habitual, que difiere de la mencionada en el trabajo de Huvelle de reutilización de bloques de código,
aunque habitualmente con un objetivo similiar. Por lo general, estas librerı́as facilitan la tarea pero
introducen una capa de incertidumbre adicional y es por ello que muchos desarrolladores prefieren
no incluirlas y desarrollar todo el código por ellos mismos.

Es por todo lo dicho anteriormente que creo que el trabajo de Huvelle aporta a una compren-
sión más exhaustiva de las prácticas de quienes desarrollan programas para sistemas informáticos.

Referencias

Huvelle, X. (2019). Especificación en programación: Semántica y Flexibilidad, En I Jornadas de

Jóvenes Investigadores de Filosofı́a de la Ciencia, Córdoba.
Siracusa, J., Arment, M. & Liss, C. (2014). Dave, Who Stinks!, En Accidental Tech Podcast. https:
//atp.fm/episodes/55-dave-who-stinks
Turner, R. (2018). Computational Artifacts: Towards a Philosophy of Computer Science. Berlin,
Heidelberg, Springer Berlin Heidelberg.

5 Al punto que hay quienes sostienen que el software es de las cosas más complejas que hemos construido (cf.
Siracusa y col., 2014)

View publication stats