Hubo un tiempo en la historia de esta industria en donde la palabra programador denotaba un gran respeto y apreciación, en particular tengo en mente la historia cuando el Profesor Edsger Wybe Dijkstra (pronunciado Edstar Dextra) inmigró a los Estados Unidos de Norteamérica y le preguntaron su profesión, dijo: programador.
Actualmente esa palabra —según creo— ya no tiene la misma connotación; en parte me parece debido a la economía de escalas y la inercia de las ideas de la revolución industrial de principios del siglo pasado. Ideas por las cuales, en un momento desafortunado, se asoció el estrato del personal poco educado y prescindible de las líneas de producción en las fábricas de manufactura al estrato de quienes con sus propias manos formulan el documento fuente del cual son creados los productos de software. Históricamente, ¿A quien se le habrá ocurrido por primera vez semejante correlación? Me propongo investigarlo, y no me asombrará si acaso se tratase de una mal interpretación como otras tantas que definen el pensamiento popular de nuestra industria actualmente (como por ejemplo el proceso de desarrollo en cascada cuyo supuesto inventor en realidad nunca ni siquiera mencionó la palabra cascada y de hecho como parte de sus conclusiones en su trabajo original dijo explícitamente que dicho proceso no debe ser ejecutado en fases secuenciales pues los resultados no serían adecuados).
Me parece actualmente —y ojala estuviera equivocado— que la palabra programador está asociada a la imagen de un chico joven y fuerte (para resistir las jornadas largas y lejos de casa), con poca experiencia, mucho entusiasmo, rápido para hablar y lento para escuchar. También en ocasiones, es el personaje que salva el día con todo tipo de suertes y trucos que solo él conoce y enmascara para conservar su poder, así como un Llanero Solitario de la programación.
Desde hace algunos años una nueva palabra ha tomado popularidad en nuestra industria, arquitecto de software, solo que en esta ocasión la cantidad de connotaciones que me he encontrado es significativamente mayor y el significado práctico me parece algo difuso. Pienso que la industria en su totalidad se beneficia cuando el significado se apega al del diccionario de la lengua española, arquitecto: persona que profesa o ejerce la arquitectura. Y a su vez, arquitectura: arte de proyectar y construir. En otras palabras, arquitecto de software: persona que profesa o ejerce el arte de proyectar y construir lógica computacional (software).
Una de las connotaciones que puedo observar asociadas al concepto de arquitecto de software es aquella derivada del tradicional arquitecto civil, cuyo significado según otro diccionario es: persona que planea edificios y supervisa su construcción. El tropezón aquí consiste en la suposición de que hacer software es similar a hacer edificios, lo cual ha resultado ser una suposición incorrecta pues —de hecho— formular lógica computacional es muy diferente de hacer edificios, y lo es en múltiples dimensiones, desde qué constituye el diseño del producto final hasta quién o qué obedece el plan trazado de construcción.
El terreno con frecuencia tiende a ser significativamente diferente al mapa que lo describe cuando estamos parados justo encima de dicho terreno, el punto de vista que se aprecia desde ese lugar suele revelar factores importantes que no se logran apreciar desde ningún otro punto de vista. La controversia de qué hace un arquitecto de software es natural pues hay muchas personas en nuestra industria que expresan sus opiniones únicamente basados en los mapas que disponen, pero nunca han estado parados en el terreno que pretenden prescribir. El dilema se presenta (como dice un muy querido amigo) "cuando la realidad impone sus reglas" y los que recorren el terreno simplemente observan que no es como dice el mapa ¿Qué hacer? Para cualquier propósito práctico, yo sugiero hacerle caso al terreno.
Propongo la siguiente definición que pienso es más apegada al terreno, arquitecto de software: persona que profesa o ejerce el arte de proyectar y formular lógica computacional en documentos técnicos ejecutables.
Lo más notable es el hecho de que frecuentemente practicantes profesionales como Grady Booch, y muchos otros autores y autoridades respetadas en la industria por el software que ellos mismos han diseñado y desarrollado, no solo imaginado, opinan lo mismo: Los arquitectos deben programar.
En otras palabras, I do subscribe to this point of view:
Software Architect's Role
"Implementation Expertise: Architect always implements. That basically means, "eat your own dog food". An architect must product designs that can be implementable software architecture. And she or he must be able to refactor when necessary. Thus, an architect needs to participate in implementing and unit-testing...." -
http://stal.blogspot.com/2006/03/software-architects-role.html
Referencias:
Should Architects Code?
Should Architects Code: Round 2
Architects Must Write Code
Testing Design
Saludos cordiales,
Marco
"Besides a mathematical inclination, an exceptionally good mastery of one's native tongue is the most vital asset of a competent programmer" -Edsger W. Dijkstra
Marco A. Dorantes es un consultor en el diseño y formulación de programas (software) desde 1987, oficio que lo llevó a la investigación aplicada en el campo de los métodos sistemáticos para diseño de software. Ha realizado diversas contribuciones públicas en la comunidad mundial de programación, tanto en foros técnicos como en software, por ejemplo AutoTest for .Net y CppUnit for C++Builder disponibles desde www.xprogramming.com