En el artículo anterior comentábamos cómo con frecuencia en la literatura sobre tecnología se pierde la visión general, la aportación y significado de una tecnología, su valor para el cliente y para el negocio y todo ello se difumina entre una miríada de detalles técnicos de importancia, probablemente secundaria.
Y veíamos cómo, en concreto, en la literatura sobre telecomunicaciones, tiende a dedicarse mucho espacio al detalle de la composición de las tramas, las primitivas de los protocolos, y otros aspectos que, siendo importantes para el detalle, no posibilitan, sino que dificultan, la comprensión global, la estructura, el verdadero conocimiento.
Pero esto no ocurre sólo con las telecomunicaciones.
En la literatura sobre software con frecuencia ocurren cosas similares.
Hace pocas fechas terminaba un libro sobre Java EE 7 (reseña muy pronto en este blog) en que, en teoría, cabría esperar una descripción de los fundamentos de esta plataforma. Pero la obra se detenía casi exclusivamente en la descripción de la programación, cómo se utilizaban por un desarrollador las diferentes APIs. Y se obviaban, sin embargo, aspectos tan importantes como la motivación e implicaciones de un modelo componente-contenedor, o cuándo elegir un tipo de componente u otro, o aspectos de escalabilidad, transaccionalidad y rendimiento o dónde se sitúa Java EE frente a otras alternativas o, por qué optar por esta plataforma.
Si en las telecomunicaciones tendemos a perdernos entre tramas y primitivas, en software es fácil detenerse en la pura sintaxis de la programación, olvidándonos de la arquitectura, las grandes líneas del diseño o las implicaciones de negocio en cuanto a eficiencia del desarrollo, escalabilidad, gobernabilidad y así un largo etcétera.
¿Por qué?
En el caso del software a lo mejor es porque el colectivo de los desarrolladores es amplio y quizá un buen segmento al que dedicar libros de tecnología pero ¿en qué fuentes pueden apoyarse, entonces, los arquitectos software, los equipos de explotación, los jefes de proyecto o los gestores de equipo técnicos? O, incluso en el caso de los desarrolladores, ¿cómo pueden hacer un software de verdadera calidad y valor de negocio si ignoran los principios arquitecturales que sustentan esas APIs que usan conociendo sólo su sintaxis, pero no otro tipo de implicaciones menos evidentes?
Árboles, árboles, árboles…
En ocasiones hermosos, en ocasiones atractivos…pero que velan nuestra mirada, que nos impiden ver más allá, que nos ocultan ese bosque tecnológico en el que deberíamos orientarnos.
Artículos de este blog relacionados
