¿El término "Ingeniería de software" es un oxímoron?

Ingeniería. Ingeniero. Engine. Máquina. Vamos a hacer una pregunta tonta y peligrosa: ¿qué máquina construye un ingeniero de software? Si te sale rápido, sospechá. Yo llevo treinta años metido en el software y todavía no tengo una respuesta que me convenza.¹

Lo interesante no es que la pregunta sea difícil. Lo interesante es que la pregunta no la inventó un crítico externo de la disciplina, ni un filósofo decidido a molestar, ni un estudiante con ganas de quedar bien en un seminario. La escribió Alan Kay, el tipo que acuñó object-oriented, en un apéndice de un manual técnico que casi nadie lee. La dejó ahí, como quien deja una bomba en el cajón de una mesa de luz, y siguió escribiendo software.

Las ingenierías clásicas se organizan alrededor de una máquina

El sustantivo ingeniería se siente robusto porque evoca algo muy específico. Las ingenierías que le dieron al nombre su prestigio —la civil, la mecánica, la eléctrica, la química— están todas organizadas alrededor de un objeto físico. El ingeniero civil diseña y supervisa la construcción de un puente: el puente es la cosa. El ingeniero mecánico diseña un motor, una caja reductora, una prensa: el motor es la cosa. El ingeniero eléctrico diseña una red de distribución, un transformador, un circuito: el circuito es la cosa.

Ese objeto físico cumple una función doble. Por un lado, ancla el vocabulario técnico: cuando dos ingenieros civiles discuten sobre momentos flectores, los dos están pensando en el mismo puente. Por otro lado, ancla la responsabilidad civil. Si el puente se cae, hay un colegio profesional, una matrícula, una firma en un plano y un juicio posible. La palabra ingeniero, en las disciplinas clásicas, no es un adjetivo que se agrega al currículum: es un contrato con la sociedad que tiene consecuencias jurídicas. La etimología no está de adorno: engineer viene de engine, y engine es esa máquina concreta que alguien firmó y que puede matarte si la firmó mal.

Las “ingenierías alternativas”

Con esa imagen en la cabeza, la lista de disciplinas que usan la palabra ingeniería con un adjetivo adelante se vuelve divertida. Ingeniería industrial, ingeniería ambiental, ingeniería financiera, ingeniería social. Y, por supuesto, ingeniería de software. El patrón es el mismo que en las “medicinas alternativas”: el adjetivo cambia el sustantivo sin pedir permiso. Medicina china, medicina ayurvédica, medicina basada en ondas cósmicas. Medicina hace el trabajo pesado — importa el prestigio — y el adjetivo pone la condición.

No estoy acusando a nadie de impostor. La ingeniería industrial tiene su historia y su cuerpo de conocimiento. La ingeniería financiera modela cosas que valen la pena modelar. Lo que pasa es que, cuando se comparan con las clásicas, a todas les falta la máquina: el objeto físico que ancla el vocabulario y la responsabilidad. Un ingeniero financiero no firma un puente. Un ingeniero industrial firma procesos, que son invisibles hasta que fallan y nadie sabe bien quién los firmó. Y un ingeniero de software firma… ¿qué, exactamente?

Una respuesta honesta empieza por reconocer que cuando le ponemos el adjetivo alternativa a la palabra ingeniería, estamos pidiéndole al sustantivo que nos preste el prestigio sin pagar los costos. Y eso, como todo préstamo no pagado, genera deuda.

La pregunta que dejó Alan Kay en 2002

En octubre de 2002, Alan Kay publicó el borrador 0.1 del manual de Croquet, un sistema de colaboración 3D hecho sobre Squeak que casi no sobrevivió a su propio entusiasmo.² El manual tenía un apéndice B titulado, literalmente, Is “Software Engineering” an Oxymoron?.³ No era un ensayo independiente: era una reflexión dentro de un documento técnico, escondida al final.

La pregunta de Kay es honesta, no retórica. No dice “la ingeniería de software es una farsa”. Dice algo más sutil: si tomamos en serio la etimología —engineer viene de engine— y miramos lo que construye nuestra disciplina, ¿a cuál objeto le estamos poniendo nuestra firma?

Importa que la pregunta la escriba Kay y no un crítico externo. Kay no está afuera tirando piedras. Kay es uno de los que fundó la disciplina: Sketchpad de Sutherland estaba en su genealogía, Smalltalk fue su criatura, el Dynabook fue su visión, el PARC fue su casa. El mismo tipo había dicho cinco años antes, en OOPSLA 1997, en una keynote titulada The Computer Revolution Hasn’t Happened Yet.⁴ Cuando alguien con ese currículum, con cuarenta años de ver a la disciplina desde adentro, pregunta si el nombre con que la bautizamos es un oxímoron, no está despreciando el campo: está preocupado. La preocupación honesta del que labura en algo y no ve cerrar la ecuación.

Tres respuestas que circulan

“El software es la máquina.” La más directa: ¿qué máquina construye un ingeniero de software? El programa mismo. El código es la máquina, ejecutándose sobre una CPU genérica. El problema con esta respuesta es la indirección. Lo que el desarrollador escribe no es la máquina: es una receta para una receta. El compilador (o el intérprete, o el JIT) decide cómo transformar el código fuente en instrucciones reales para una CPU concreta, sobre un sistema operativo concreto, sobre un kernel que puede interrumpir el proceso en cualquier instante. El plano del ingeniero civil es el puente que se construye; el código del desarrollador está a tres o cuatro capas de la cosa que efectivamente corre. Y la cosa que corre se modifica todos los martes — no hay un as-built que certificar, porque nunca termina de construirse.

“Ingeniería es aplicar conocimiento científico a un problema práctico.” Esta es la posición de Mary Shaw en su artículo de 1990:⁵ el software ya tiene ciencia (teoría de computabilidad, lógica, análisis de algoritmos), ya tiene práctica (sistemas que funcionan), y por lo tanto tiene derecho a llamarse ingeniería. Es una respuesta defendible y sofisticada. Pero es blanda: pierde el lado de responsabilidad civil de la palabra. Un farmacéutico también aplica conocimiento científico a un problema práctico, y no por eso se llama ingeniero farmacéutico. La ciencia-aplicada-a-problemas-prácticos es condición necesaria, no suficiente.

“El software es matemática aplicada.” Esta es, aproximadamente, la posición de Dijkstra, visible en los EWD y especialmente en EWD 1305, Answers to questions from students of Software Engineering.⁶ Para Dijkstra el problema no era la ingeniería en sí: era pretender hacerla con el rigor rebajado del apuro comercial. Su propuesta implícita era abandonar la palabra ingeniería y aceptar que el software es una rama de la matemática aplicada. Es la respuesta más honesta de las tres: acepta el oxímoron y lo resuelve renunciando al sustantivo equivocado. También es la menos popular, porque nadie quiere poner “matemático aplicado” en LinkedIn.

Por qué no es un debate académico

Uno podría pensar que todo esto es filosofía de café, y en parte lo es. Pero tiene consecuencias prácticas. Las ingenierías clásicas tienen códigos de ética profesional ligados a colegios que pueden expulsarte, matrícula obligatoria para firmar ciertos trabajos, responsabilidad civil objetiva, seguro obligatorio, y controles previos a la habilitación. Ninguna de esas cosas existe, en sentido fuerte, para el software.

El Software Engineering Code of Ethics de ACM/IEEE-CS, publicado en 1999,⁷ es un documento valioso, pero no tiene fuerza vinculante: nadie pierde la matrícula por violarlo, porque en la inmensa mayoría de las jurisdicciones no hay matrícula que perder. Hubo intentos de regular la profesión, y todos terminaron diluidos. Texas ofreció entre 2013 y 2019 una licencia PE específica para Software Engineering; NCEES la discontinuó por falta de candidatos —en cinco administraciones del examen se anotaron 81 personas en total—.⁸ Alberta, que sí restringía el uso del título software engineer por la ley de su colegio profesional, perdió en noviembre de 2023 una causa contra Getty Images y Jobber; en julio de 2024 la legislatura provincial sacó el título de la ley regulada.⁹ El intento siempre choca con la misma pregunta: ¿cuál es exactamente el software que debe regularse? ¿El código de la computadora del auto? ¿El de la tablet? ¿El del sitio de comidas a domicilio?

Tom DeMarco —coautor de Peopleware, autor del libro de métricas Controlling Software Projects (1982)— publicó en IEEE Software en 2009 un texto donde se renuncia a sí mismo.¹⁰ El DeMarco joven había escrito la frase más citada del campo, “You can’t control what you can’t measure”; el DeMarco de 2009 corre el dial de la incomodidad un click más allá. La conclusión no es “medí lo correcto” —ese sería el consejo blando—, es algo peor: el reflejo de control te selecciona los proyectos equivocados, los de bajo retorno donde efectivamente se puede medir y controlar todo. Los proyectos que valen la pena —los que cambian el negocio, los que transforman a una empresa— son por definición experimentales: su construcción tal vez no, pero su concepción sí. La distinción que cierra el artículo es la que más sirve acá: una cosa es to engineer software (verbo), que tiene todo el sentido del mundo; otra cosa es software engineering (sustantivo), que terminó denotando un combo específico —procesos definidos, walkthroughs, matrices de trazabilidad, métricas, planificación rigurosa, estándares de código— que persigue consistencia y predictibilidad. Que el autor del libro de métricas más influyente firme esa renuncia es lo que le da peso.

Mientras tanto, en los contratos seguimos firmando “Ingeniero de Software” y en las licencias del producto seguimos repartiendo “AS IS, WITHOUT WARRANTY OF ANY KIND”. El sustantivo de la portada dice una cosa, la letra chica dice exactamente la opuesta. En ninguna otra ingeniería pasa eso.

Una aspiración, no una credencial

En 2021, en GOTO, Kay volvió sobre el asunto con una charla titulada Aspiring to Learn The Engineering of Software.¹¹ El título es cuidadoso: aspiring to learn. No dice que el software ya sea una ingeniería. No dice que no vaya a serlo nunca. Dice algo más útil: es una aspiración. Hay prácticas —el testing sistemático, la verificación formal, la disciplina del diseño, la honestidad con las trade-offs— que se parecen más al trabajo del ingeniero civil que a la improvisación del artista. Y hay prácticas —firmar antes de pensar, copiar de Stack Overflow a ciegas, desplegar porque la consola da verde— que no se parecen a ninguna disciplina.

La posición que me quedó después de treinta años de hacer esto es modesta. Ingeniería de software no es un oxímoron, pero tampoco es todavía una descripción: es una aspiración. Sigo escribiendo software, sigo firmando contratos que usan la palabra ingeniero, y sigo poniendo “desarrollador” en el CV cuando tengo que ser honesto. Voy a poner ingeniero en el CV con todas las letras el día que encuentre la máquina que estoy firmando. Kay no la encontró en cuarenta años. ¿Qué podría pretender yo en treinta? Por ahora aspiro a aprender la ingeniería del software, como dice el título de su charla, y tomo ingeniería como objetivo, no como credencial.

• Filosofia
• Alan Kay
• Ingenieria Alternativa
• OOPSLA
• Profesion
• Dijkstra