Pero, la informática, el desarrollo software… ¿qué es? ¿arte, artesanía, ciencia o #esingeniería?

Hace unos días se dio por inaugurada la enésima edición del debate sobre si la carrera universitaria de informática, o la informática en general, es ingeniería o no lo es. No penséis que este debate es nuevo, no. Es una “déjà vu” que se repite cada cierto tiempo.
Los más antiguos del lugar cuentan, yo por aquellos entonces ni había empezado a estudiar informática, que empezó en el 86, con la Ley 12/1986 sobre regulación de las atribuciones profesionales de los arquitectos e ingenieros técnicos, en el 99 con la LOPD, en el 2002, etc. Y ahora estamos en la última reedición del debate, la v 2013, a raíz de la Ley de Servicios Profesionales que separa a informática del resto de ingenierías.
En España, por lo general, el debate siempre ha surgido después de algún movimiento político, cuando se ha creado una nueva ley de carácter profesional, cuando se han modificado los estudios universitarios, etc. Y, en todas las ocasiones, detrás del debate había siempre un intento de para separar a “los informáticos” del resto de ingenierías.
Más allá del ámbito español, este es un tema tratado con profundidad desde hace mucho tiempo. Hasta el punto de que grandes nombres de la profesión han dedicado destacados textos al tema de si la creación de sistemas informáticos es ingeniería o no.
Por ejemplo, el mismo Steve McConnell, autor del famosísimo “Code Complete”, el que dicen es el libro sobre desarrollo software más vendido (te dejo un post sobre el libro) o del “Rapid Development”, dedicó un capítulo entero de su libro “Professional Software Development”, a defender que “Software Engineering, Not Computer Science” (puedes leerlo aquí). En su opinión, “la respuesta a esa pregunta es clara: el desarrollo software debe ser ingeniería”.
Pero, sin quitarle honores al anterior, el texto más influyente sobre este popular debate es el que escribió Parnas. Parnas, del que ya hablamos hace un tiempo por aquí, es conocido por crear el concepto “ocultación de la información” (tan aplicado en OO) y por demostrar la inviabilidad tecnológica del plan de Ronald Reagan para crear un escudo de satélites antimisiles que defendiese a EE.UU. frente a un ataque nuclear por parte de la URSS.

En el 1999, Parnas publicó en IEEE Software el artículo “Software Engineering Programmes Are Not Computer Science Programmes” (lo puedes descargar aquí), del que he querido extraer algunos párrafos:

Sería mucho más fácil de identificar Ingeniería Software como una nueva rama de la ingeniería. En lugar de tratar de ingeniería de software como un subcampo de la ciencia, debería tratarse como una más del conjunto {Ingeniería Civil, Ingeniería Mecánica, Ingeniería Química, Ingeniería Eléctrica, …}.

En muchos lugares, por ejemplo en las ofertas de empleo, «Software Engineer» se utiliza como un eufemismo de «programador.» Muchos autores parecen asumir que la única responsabilidad de un ingeniero de software es escribir buen código. Pero no podemos olvidar el significado histórico y legal de «Ingeniero».

Un ingeniero es un profesional responsable de la producción de productos que aptos para su uso. Para estar seguro de que un producto es apto para su uso requiere una comprensión del entorno en el que se utiliza. En consecuencia, los llamados «Ingenieros de Software» necesitan de conocer muchas cosas que no son sólo parte del desarrollo.

Alguna reflexión final

Parece que fuera de España el debate quedó zanjado hace muchos años. Al menos en lo que a terminología se refiere, nadie discute el “engineering” del “software engineering”, sino mira cómo lo usan Google, Facebook, y otras, en sus ofertas de empleo y perfiles profesionales.
A nivel político, en España, parece que en vez de pensar cómo mejorar el sector de las tecnologías, que este nos ayude a salir de la crisis, o cómo atajar la caída de matrículas en las carreras universitarias de informática (dejo un post), nos metemos en este tipo de debates que no dejan de parecer ridículos con la que tenemos encima, y a saber con que objetivo final.
Y ahora algún comentario personal para los de dentro, los del sector.
En estos días ha sido grato ver cómo hay unidad, y una gran mayoría, en el sector respecto a que informática es ingeniería (la petición de firmas en change.org, aquí tienes el enlace, lleva 14.654 firmas en el momento en que escribo este post). Enhorabuena.
Pero ello no quita que en estos días se puedan leer cosas raras, puntuales, pocas ciertamente, en contra. Para que estas cosas raras no produzcan duda paso a comentar dos de ellas:

• Que informática sea ingeniería no quiere decir que tengamos que hacer las cosas como las hacen los arquitectos o los ingenieros que hacen puentes (te dejo este post al tema), ni que volvamos al uso único del ciclo de vida en cascada. Los ingenieros químicos, son ingenieros, y no creo que apliquen principios de construcción de puentes a su trabajo.

• Que «informática sea ingeniería» no quiere decir que unos malvados Colegios vayan a regular la profesión y nadie pueda trabajar en informática sin su permiso, primero porque si la informática es ingeniería lo es, existan Colegios o no, y segundo, porque a estas alturas de la película no se quien se puede creer que en España algún día la profesión del informático se va a regular (no creo que eso pase nunca), y, aunque se regulase, que no va a pasar, sería una regulación light.

 
No te engañes, si informática deja de ser ingeniería oficialmente a efectos políticos, informática perderá la poca igualdad que le queda respecto a las otras ingenierías, y eso… no va  a ser precisamente para que nos vaya mejor profesionalmente.

• Acerca de
• Últimas entradas

jgarzas

Ph.D. en informática, Postdoctorado en la Carnegie Mellon (EE.UU) e Ingeniero en Informática.

Primera vez que me tocó hacer una gestión Ágil en una empresa... año 2001. Desde entonces he trabajado en, o para, más de 90. Y he formado a más de 2000 alumnos.

También soy profe de la Universidad Rey Juan Carlos.

Últimas entradas de jgarzas (ver todo)

• Las 3 matrices de priorización Ágil - 19 octubre, 2023
• Etapas del Agile Product Management - 12 octubre, 2023
• Agile Product Management: DINÁMICA «Árbol Solución Oportunidad» + «Valores Esperados» - 5 octubre, 2023