iNGENET - La comunidad de la ingeniería mexicana

Hemos explorado a los usuarios de a pie y sus relaciones con los dispositivos modernos, abordemos ahora la relación entre los creadores de tecnología y sus realizaciones.

¿Que debe ver un ingeniero, una caja negra o una caja blanca? Es decir, ¿un ingeniero debe conocer por qué un artefacto que utiliza cotidianamente funciona  o simplemente debe contentarse con saber cual es la conducta del artefacto sin preocuparse de los por qués?

Un ingeniero novel contesta que debe ver los sistemas como si fuera cajas blancas y debe conocer a detalle la manera como funcionan. Un ingeniero con cierta experiencia no sólo sabe que hay muchas cosas en la profesión que no son cajas blancas para él, sino que hay muchas cosas en que desconoce, inclusive, algunas reglas básicas del funcionamiento. Pongamos algunos ejemplos.

En las empresas modernas se compra software. En definitiva, aunque se desarrolle software a la medida siempre se compra alguna porción de software a un tercero. Sea el sistema operativo, o el compilador, o el servidor de aplicaciones. Y cada uno de esos macroelementos es una caja negra de la que desconocemos muchos detalles. ¿Hay manera de evitar el IDE del compilador y, por decir algo, cambiar el tamaño de la pila de datos asignado por omisión al programa, o la dirección de la primera instrucción ejecutable? ¿Sabía que prácticamente todos los compiladores invocan a un compilador en línea de comandos y que es posible interceptar la llamada y modificar la lista de parámetros?

Basta con darse una vuelta a los foros en la red para darnos cuenta de cuantos elementos nos son desconocidos. No hay ayuda tan completa que pueda explicar cada vericueto del comportamiento de los elementos de software. ¿No se ha topado con un error esquivo, o con una documentación tan pobre que ha tenido que buscar en mil foros alguna respuesta? ¿No le ha pasado que a veces ha encontrado mil veces la pregunta en los foros, (a veces colocada años atrás) pero no la respuesta? Y esto es lo mismo para el software comercial y para el software libre. Esta es una casa enorme donde todos somos jaboneros.

Quisiera puntualizar que estoy viendo el software en este punto como un televisor. Un aparato que tiene controles que están allí para que uno ajuste al aparato. Sin necesidad de abrirlo o de saber que hay un menú escondido que me da acceso al menú de servicio. Hablo sólo de lo que el fabricante me permite manipular. Yo realizo programas, subo aplicaciones a servidores, instalo componentes en una computadora y siempre hay una gran cantidad de detalles que no conozco sobre los complejos componentes de software. Errores en los lenguajes en los que no comprendo porque el programa hace lo que hace. Errores de tiempo de ejecución en los que veo que algo falla inexplicablemente, a pesar de que reviso programas y configuraciones y simplemente no hay una sola pista de que es lo que pueda estar mal. Los componentes se comportan como cajas negras en las que desconozco porque se comportan de esa manera.

Y puede ser simple falta de capacitación, o una negligente documentación. Lo cierto es que cada vez con más frecuencia encontramos componentes tan complejos que no es posible conocerlos completamente. Y si esto es cierto para muchas personas que nos dedicamos a la informática, interpólese el asunto para aquellos que usan la computadora como herramienta auxiliar de su labor.

Por supuesto que acepto los argumentos en el sentido de que estos componentes son diseñados por terceros y es difícil verlos como cajas blancas. Entonces examinemos el caso de los artefactos que diseñamos nosotros.

Como ingenieros acudimos a nuestros centros de trabajo a diseñar toda clase de artefactos producto de nuestro ingenio. Pero con raras excepciones, el fruto de nuestros afanes implica división en el trabajo. Algunos elementos en el equipo desarrollan ciertos elementos y otros diseñamos componentes diferentes. Todos conocemos los principios fundamentales de nuestra profesión, y tratamos de hacer un trabajo realmente profesional, documentando el resultado de nuestros análisis. Al final tenemos un producto que funciona gracias a muchas horas en que el trabajo intelectual ha puesto su mejor empeño en obtener el mejor artefacto. En cada nueva versión, con cada mejora del artefacto, tenemos un producto más interesante y también complejo. Más tarde o más temprano se llega a un punto en que cada nueva evolución se vuelve más difícil. Tal vez ha escuchado estas frases: “No tengo idea de las implicaciones de ese cambio”, “Pues habrá que realizar pruebas para saber como se comporta”, “No estoy seguro de que ésa adecuación sea factible”. Todas estas frases implican desconocimiento del componente.

Y no se llega a ésta situación por negligencia profesional. Simplemente, el componente se vuelve tan complejo, han intervenido tantas personas, se ha desarrollado a lo largo de mucho tiempo, que en un momento dado simplemente no hay quien conozca el componente, los componentes o sus interacciones a detalle.

Hoy or hoy, por ejemplo existe una cierta filosofía informal de escritura de software basada en la filosofía del “Si no esta descompueto, no lo toques”. Es la filosofía el if: “Si se cumple la nueva condición entonces haz las nuevas acciones En caso contrario Deja aquí el resto del código y no lo toques”. Cuando un código ya no se toca porque “se descompone”, entonces tenemos un caso clarísimo de un componente que nació como caja blanca y que al cabo de los años ha terminado por convertirse en una caja negra. En una caja que nos da miedo abrir, tocar por dentro, modificar de alguna manera, porque suceden cosas que no comprendemos muy bien. Se vuelven cajas tenebrosas.

Entonces, ¿Debe un ingeniero comprender sus sistemas, de manera que estos sean cajas blancas, o debe ignorar su propia ignorancia y aceptar que sus propias creaciones son artefactos que no comprende como funcionan plenamente? ¿Debe el ingeniero aceptar que sus creaciones son tan complejas que el mismo creador no conoce cada detalle?

Estas no son preguntas retóricas. Son preguntas que creo debemos contestar de manera profundamente reflexiva, ya que en las universidades tenemos el primer acercamiento de los nuevos profesionales y los respuestas a esta preguntas impactan lo que se imparte en un curso. ¿Deben los ingenieros en computación o ingenieros en sistemas digitales conocer los transistores? ¿Deberían simplemente saber conectar una NAND o de plano ignoramos todo eso y vamos directamente el diseño digital basado en componentes regrabables, en memorias persistentes pues ya nadie diseña con compuertas elementales? ¿Deberíamos saber a detalle el estándar IEEE754,el RFC 3493, RFC 3542 o cualquier otro, o simplemente usar las cosas allí detalladas y olvidar, por ejemplo cual es la representación interna de un número flotante? ¿Es realmente suficiente ver funcionar un WebService sin comprender al socket que tiene embebido? Yo he encontrado problemas en el desarrollo de sistemas motivados porque las acciones que realiza un webService al ser invocado no son claras para los elementos del equipo de desarrollo y por tanto se invierte mucho tiempo en la solución de problemas que de otra forma son triviales.

En mi desarrollo profesional he encontrado problemas que se solucionan sólo cuando se conoce al sistema como una caja blanca. Y me queda claro que no puedo conocer todo a fondo. ¿Como debemos desarrollar la ingeniería en este país? ¿Como la llevamos hoy en día?