Desarrollador, no ingeniero. Y por qué importa

8 min de lectura

El ejercicio de marca más exitoso en la historia de la tecnología

Un término que pretendía incomodar

En 1968, el profesor Friedrich Bauer organizó una conferencia de la OTAN en Garmisch, Alemania. Eligió “Software Engineering” como título. Brian Randell, uno de los asistentes, confirmó después que la elección fue “deliberadamente provocadora.” La industria del software se ahogaba en proyectos fallidos, presupuestos desbordados y sistemas que no funcionaban. Llamarlo “ingeniería” era un desafío: empiecen a comportarse como ingenieros. Apliquen disciplina. Sigan procesos. Construyan cosas que no se derrumben.

Margaret Hamilton usó el mismo término en la NASA durante el programa Apollo. Lo decía literalmente. Su equipo construía software de vuelo donde los errores mataban astronautas. El rigor era real. Las pruebas eran exhaustivas. Los estándares estaban documentados y se cumplían. Eso era ingeniería genuina aplicada al software.

El problema es lo que pasó después. La aspiración nunca se convirtió en realidad para la gran mayoría de la industria. Adoptamos el título y nos saltamos la disciplina. Dijkstra lo vio con claridad. Observó cómo Data General ascendió a todos sus programadores a “software engineer” de la noche a la mañana y llamó al campo entero “The Doomed Discipline,” condenada porque “no puede siquiera acercarse a su meta ya que su meta es autocontradictoria.”

Escribió eso en 1988. Nada ha cambiado.

Lo que los ingenieros realmente hacen

Un ingeniero civil calcula tolerancias de carga usando fórmulas validadas durante siglos. Un ingeniero eléctrico diseña circuitos contra restricciones físicas conocidas. Un ingeniero mecánico especifica materiales con límites de estrés documentados. Son profesionales que aplican estándares conocidos a problemas conocidos. La física está resuelta. La matemática está probada. Los códigos de construcción existen porque personas murieron hasta que alguien los escribió.

Cuando un puente falla, se investiga. Cuando falla porque el ingeniero ignoró estándares establecidos, se revoca la licencia. Hay responsabilidad. Hay un cuerpo de conocimiento con límites claros. Hay un proceso de licenciamiento profesional con exámenes, períodos de formación, educación continua obligatoria y consecuencias legales por negligencia.

El software no tiene nada de esto. En Estados Unidos se introdujo un examen de Ingeniero Profesional para software en 2013. Lo discontinuaron en 2019. No hubo suficientes personas interesadas en presentarlo. La ACM e IEEE examinaron la idea de licenciar profesionales del software y concluyeron que “the framework of a licensed professional engineer, originally developed for civil engineers, does not match the professional industrial practice of software engineering.”

Lean esa frase otra vez. Las dos organizaciones profesionales de computación más grandes del mundo dijeron: lo que hacemos no coincide con lo que hacen los ingenieros. Y luego todos siguieron usando el título de todas formas.

La excepción californiana que se comió al mundo

En partes de Canadá, llamarse ingeniero sin acreditación es ilegal. En varios países europeos, el título está regulado. En muchos países latinoamericanos, el título de ingeniero requiere un grado universitario en ingeniería y a veces registro profesional ante un colegio de ingenieros.

A California no le importa. Y de ahí es donde toda la industria global del software toma sus señales culturales.

Silicon Valley convirtió “engineer” en el título predeterminado para cualquiera que escriba código. Ian Bogost lo capturó perfectamente en The Atlantic en 2015: “In the Silicon Valley technology scene, it’s common to use the bare term ‘engineer’ to describe technical workers. Somehow, everybody who isn’t in sales, marketing, or design became an engineer.”

¿Por qué? Varias razones, ninguna relacionada con ingeniería real:

Prestigio. “Software engineer” suena mejor en una tarjeta de presentación que “programador.” Como observó un académico: “If you are a programmer, you might put ‘software engineer’ on your business card, never ‘programmer’ though.” Mismo trabajo. Mejor marca.

Reclutamiento. Las startups compitiendo por talento en un mercado laboral ajustado descubrieron que “engineer” atrae más postulantes que “developer.” El título se convirtió en herramienta de contratación, no en descripción de la práctica.

Estructuras de compensación. Los títulos de puesto afectan las bandas salariales. “Engineer” cae en categorías de compensación más altas que “developer” o “programmer” en los sistemas de recursos humanos corporativos. El título conlleva un premio salarial que no tiene nada que ver con rigor o disciplina.

Nadie que diga basta. A diferencia de la ingeniería civil o mecánica, no hay junta de licenciamiento, no hay organismo de acreditación, no hay marco legal que impida a una empresa llamar ingeniero a cada programador. Así que lo hacen. ¿Por qué no, si el título no cuesta nada y paga más?

El propio libro de Google, “Software Engineering at Google,” intentó redefinir el término por completo: el desarrollo de software sería “programming integrated over time.” Un marco interesante. También una admisión de que la palabra “engineering” se está estirando hasta significar algo completamente diferente de lo que el resto de la profesión de ingeniería entiende.

Por qué la distinción realmente importa

Esto no es pedantería. La etiqueta moldea expectativas. Y las expectativas equivocadas matan proyectos.

Cuando le dices a una junta directiva que tienes “sesenta ingenieros de software,” escuchan “sesenta profesionales aplicando estándares conocidos para producir resultados predecibles.” Esperan precisión de diagrama de Gantt. Esperan que más ingenieros signifique entrega más rápida. Esperan el tipo de predictibilidad lineal que funciona para construir una bodega pero que nunca ha funcionado para construir software.

El desarrollo de software es a veces artesanía y a veces oficio, pero rara vez es ingeniería en el sentido tradicional. Un oficial instala una cocina siguiendo patrones establecidos. Un artesano diseña y construye una pieza a medida. Un ingeniero calcula tolerancias de estrés para un puente. ¿Un desarrollador? Un desarrollador descubre qué construir mientras lo construye. Los requisitos cambian a medio camino. Los usuarios no saben lo que quieren. La tecnología se mueve bajo tus pies. Esto es creación bajo incertidumbre, no aplicación de estándares conocidos.

La etiqueta de “ingeniería” alimenta la fantasía de que los marcos de gestión pueden entregar la misma predictibilidad para el software que entregan para la construcción. Por eso las empresas siguen planificando proyectos de seis meses con plazos fijos, por eso contratan según un plan en vez de adaptar el plan a la realidad, y por eso se sorprenden cuando el cronograma se desvía. Los puentes no pivotan. El software sí. O debería.

Los electricistas tienen una autoridad que los desarrolladores no tienen, y parte de la razón es que los electricistas no pretenden ser algo que no son. Tienen un alcance claro, competencia regulada y el poder de decir no respaldado por código (el de construcción). Los desarrolladores de software han tomado prestado un título prestigioso sin la infraestructura de responsabilidad que lo hace significativo.

Lo que realmente somos

El desarrollo de software es una disciplina creativa, iterativa, que se realiza bajo incertidumbre radical. Los requisitos están incompletos. Las herramientas evolucionan continuamente. El espacio de soluciones no está limitado por la física. Dos desarrolladores resolviendo el mismo problema producirán soluciones fundamentalmente diferentes, ambas pueden funcionar. Eso nunca pasa con los cálculos de puentes.

Esto no hace que el desarrollo de software valga menos que la ingeniería. Lo hace diferente. Una disciplina diferente con restricciones diferentes que requiere enfoques de gestión diferentes. Tratarlo como ingeniería no es un cumplido. Es un malentendido que lleva a malas decisiones.

Tratar a los desarrolladores con respeto empieza por llamarlos lo que son. No porque “desarrollador” sea una palabra más bonita, sino porque la precisión en el lenguaje produce precisión en las expectativas. Cuando entiendes que el desarrollo de software es trabajo creativo realizado bajo incertidumbre, dejas de pedir estimaciones fijas para problemas novedosos. Dejas de medir la productividad en líneas de código. Dejas de asumir que agregar personas hace las cosas más rápidas.

Los mejores equipos de software con los que he trabajado no se llaman ingenieros. Se llaman desarrolladores, o simplemente el equipo. Se enfocan en prácticas técnicas que realmente producen resultados: desarrollo guiado por pruebas, integración continua, desarrollo basado en tronco, especificaciones ejecutables. Son disciplinas, sí. Pero son disciplinas de oficio y descubrimiento, no disciplinas de física aplicada.

El título no cambiará. El pensamiento debería

Silicon Valley ganó esta guerra de nombres hace décadas. “Software engineer” está incrustado en ofertas de trabajo, estructuras de compensación, solicitudes de visa y perfiles de LinkedIn en todo el mundo. Nadie va a renombrar la industria.

Pero el pensamiento detrás del título puede cambiar. Los ejecutivos que entienden la diferencia entre ingeniería y desarrollo toman mejores decisiones sobre plazos, presupuestos y estructuras de equipo. Dejan de esperar predictibilidad de fábrica del trabajo creativo. Empiezan a invertir en capacidad técnica en lugar de adopción de marcos.

Llámese como lo exija el sistema de recursos humanos. Ponga “engineer” en su LinkedIn si lo lleva más allá del filtro de palabras clave del reclutador. Pero cuando se siente en una reunión de planificación y alguien pregunte por qué el proyecto no puede planificarse como un proyecto de construcción, ya sabrá la respuesta.

Porque no es ingeniero. Es algo diferente. Algo más difícil de gestionar, más difícil de predecir y, en muchos sentidos, más difícil de hacer bien. Es desarrollador. Y eso no es un premio de consolación. Es una descripción más honesta de una realidad más compleja.