El cuento de Paco y la ingeniería del

software
Por
Sergio Martín

Esto es uno de los diagramas que

hacemos los informáticos, se llama diagrama de caso de uso. En este caso
expresa (de forma simplificada) lo que puede hacer un Chef y un Crítico de
comidas en una parte de una aplicación (programa) sobre un restaurante. El
ejemplo está extraído de la wikipedia no se me ocurría un ejemplo sencillo, la
verdad.

Nota inicial: debido a que la Ingeniería del Software es un tema muy aburrido,
sobretodo cuando uno se inicia a él, he decidido contar de qué va el tema por
medio de una especie de cuento, para entender sólo la idea básica (qué es, para
qué se usa y por qué se usa). En mi caso me encanta la Ingeniería del
Software, es más una buena parte del grado que estoy cursando va de ello.
Hasta ahora sé lo suficiente de esta rama, como para haber aprobado una
asignatura anual sobre ingeniería del software al final de mi antigua carrera.

Paco no era un chico normal. Para nada. Para empezar, él en vez de nacer con
un pan bajo el brazo, nació con su propio driver para el manejo de la placenta.
Cuentan que antes de aprender a hablar castellano, aprendió C puro. Incluso a
los cuatro años ya había creado su propio compilador. Y cuando cumplió siete
años, ya tenía lista su propia distribución de Linux.

Pero no todo fue oro. En la adolescencia fantaseo con cosas prohibidas como
fueron un Windows XP pirata, aunque en una máquina virtual, y toda una
pandilla de endemoniados programas privativos. En esa temporada su camello
se llamaba Internet Explorer, él se dedicaba de distribuir sus virus en forma de
esos programas. Se metía en foros y se reía de los usuarios que se tragaban las
bromas pesadas que acababan con sus ordenadores en la casa de aquel vecino
informático, siempre disponible para echar un cable cuando un ordenador se
rompía en el vecindario. De forma paradójica, el adolescente Paco también era
uno de esos vecinos informáticos que arreglaban ordenadores gratis.

Para Paco las asignaturas de letras siempre fueron para fracasados (pero él
bien que las aprobaba raspando), y una vez que terminó su bachillerato se
enfrascó en una, para él apasionante, carrera de cinco años llamada Ingeniería
Informática Superior, lo cual, desde su simplista punto de vista, le dio total
legitimidad para sentirse superior ante los alumnos de magisterio.

Allí, entre asignaturas a las que fusilaba con matriculas de honor con sólo su
mirada, conoció a su gran, verdadero y único amor. Al principio, lo típico, que
si los primeros tonteos, que si te toco una variable por aquí, que si te rodeo
con un bucle. Y luego ya fueron a saco, que si te meto una multitarea pero
antes pongo una protección synchronized. Ella tenía un nombre, ella se
llamaba Java.

Y mira que sus compañeros de universidad, que le respetaban y le veneraban

(siempre que acudiera él para ayudarles en los ejercicios o en algún que otro
examen), le dijeron a Paco que su obsesión por Java no era normal. Pero él ni
caso, oye, en su mundo Java no era un lenguaje de programación, sino lo más
parecido a su media naranja.

Pero con lo que Paco no contó es que cualquier carrera de informática es una
carrera que, básicamente, comienza por el final y acaba por el principio (un
paréntesis: no quiero decir con esto que todas las asignaturas de último curso
deban de ser de primero). Si al principio la asignatura más importante era la
que trataba más sobre informática, al final es la que trata más sobre economía
y empresariales aplicada a la informática. Organización del trabajo,
diagramas, Metrica 3, documentación,… Todo un cumulo de letras que a Paco
le dejó KO mientras la malvada asignatura reía y reía sobre él. El gran
enemigo de Paco se llamaba Ingeniería del Software, y le persiguió durante
toda su vida.

Porque cuando Paco creyó que ya había acabado con Ingeniería del Software,
con un notable (la nota más baja de su carrera), resultó que su enemigo nunca
moría. Eran como el bien contra el mal, la vida y la muerte, el escepticismo
científico y la pseudociencia, Sonic y Dr. Robotnik,… Ingeniería del Software
siempre estaba allí, desde el proyecto fin de carrera de Paco, hasta todo
trabajo que pisó. Él decía que sólo quería ser un programador por tal de no
saber nada de Ingeniería del Software. Sin embargo, el resto de compañeros
suyos sí optaron por subir de categoría, estando cada vez más y más en
contacto con la Ingeniería del Software, hasta llegar a Jefe de Proyecto, que
era para Paco como declararse un esbirro de la Ingeniería del Software.
Hasta que un día le tocó a él. La vida adulta le obligó a comportarse bien, a
enderezarse, y tomar la senda de la Ingeniería del Software. A Paco ya le
tocaba vivir con su novia de carne y hueso y dejar de una vez de ser un
parásito de sus padres. Y cuando llegó ese día, la Ingeniería del Software y él
se sentaron en una misma habitación para firmar las paces. En el contrato
ponía un nombre temible para Paco, y era ‘Analista’.

Así que la Ingeniería del Software se sentó delante suya, con traje, corbata y
zapatos. Los dos bandos extremos alcanzarían un pacto final. Y se reprodujo
el siguiente dialogo entre ellos:

– Te estoy dando una bonita oportunidad, Paco. De una vez debes de

reconocer la verdad.

– ¿Qué verdad?

– No lo notas, ¿verdad? – y le miró a los ojos – ¿Aún no eres consciente del

gran daño que has hecho? A tus propios compañeros de universidad, a tus
compañeros de trabajo, a tus superiores,… Todos ellos lo saben, Paco. Saben
que nunca cumpliste las reglas. Saben lo que haces para seguir en tu puesto,
pero ellos, idiotas, piensan que se debe todo a que no les comprendes. Les da
vergüenza decirte la verdad.

– No sé a qué te refieres. Yo programo perfectamente. Mi código está

tabulado correctamente, no tengo errores de programación, y siempre las
cosas funcionan a la primera. Además si estoy aquí, apunto de tener un
aumento de puesto y sueldo, será por algo.

– Claro que sí, rata del conocimiento. Dime Paco, ¿cuándo fue la última vez
que dejaste un comentario en el código? ¿Sabes que ayer otro becario más
rogó a los pies de los de recursos humanos que ‘por favor, sáquenme de este
proyecto, no puedo más’, tras intentar entender una sola línea de un programa
hecho por ti? El pobre, él sólo quería comenzar su carrera laboral tras terminar
la universidad. Pero claro, resulta que, tras tantos años que has estado como
programador, más del 80% del código de esta empresa ha sido creado por ti,
lo que está causando un gasto enorme en personal cualificado. Además de un
código complicado y difícil de entender, ni un misero comentario explicando
qué haces. Han habido tantos que no han soportado las pruebas, Paco. Tantos.

– Eso es mentira.

– Ah, sí. Con que ésas tenemos. Ahora verás. – Y la Ingeniería del Software le
pasó a Paco una hoja con un subprograma – Venga, valiente, adivina qué hace
eso.
– Pues ya lo pone aquí, en el título
“eliminaUsuarioConContraseña50EnEstadoErroneo9586”.

– ¿Y eso significa el qué?

– Pues, déjame que mire un poco el código. Y…

Pasó media hora hasta que Paco se dio por rendido.

– ¿Pero quién demonios hizo este código?

– Tú fuiste Paco. Tú, nada más llevar dos meses trabajando en esta empresa.
Y éste es sólo un ejemplo del gran mal que has dejado aquí. Al contrario que
tus compañeros, nunca quisiste usar ni siquiera el más mínimo de mis
fundamentos: comentar el código y dejar las cosas claras para que otro
programador cualquiera las comprenda con tan sólo echar una ojeada. Cosas
como ésta le costó jugarse a más de uno de tus antiguos jefes el puesto, debido
a que no se verificaban las principales normas de calidad del software, y
tenían que mentir en la fichas de calidad (pero tuvieron suerte porque nadie
intentó contrastar datos). Sí, eres un gran programador y eres capaz de
resolver problemas muy difíciles, y por eso eres útil para esta empresa, y por
esto es por lo que te quieren ascender. Pero antes de subir debes pensar que
nunca hiciste caso.

>> Pienso que ahora te aplicarás como todos, estoy seguro. Cuando tengas
que organizar un proyecto con diagramas, cuando tengas que echar un cable
para que tus superiores planifiquen los proyectos y estimen horas (teniendo
siempre en cuenta que el rendimiento de cada persona es diferente), cuando
tengas que pensar en que el cliente quiere un producto de calidad, ajustado a
lo que él quiere, e intentando siempre inferir lo que él intenta decir qué quiere,
pero no te lo dirá explícitamente (pues poca gente sabe lo que realmente
quiere cuando va a comprar algo). E incluso más de una ocasión teniendo que
rechazar a tu querida Java como opción para un proyecto, porque no se adapte
a lo que quiere el cliente.

>> Y también tendrás problemas. Puede que tengas que hacer el esfuerzo de
escribir documentación de análisis mientras los programadores hacen sus
tareas, puede que el cliente le diga a tu equipo, de forma clara, que el producto
no tiene nada de lo que dijo, y tengas que volver a dibujar diagramas. Tendrás
que sacar requisitos casi de la nada en más de una ocasión. Discutirás con
otros analistas e incluso con jefes de proyecto. Sin contar la documentación de
cada cosa que hacéis, pues todo debe quedar perfectamente detallado, desde la
funcionalidad hasta las pruebas.
>> Y te alejarás de la programación progresivamente, hasta llegar a Jefe de
Proyecto, puesto en el cual tendrás que ocuparte más de la planificación del
proyecto, la documentación de calidad, las largas reuniones, el contacto
directo con el cliente, y de viajes. Porque esto es realmente lo que aceptaste
ser al elegir una ingeniería informática.

Paco firmó el contrato, aceptando su nueva vida.

Es curioso pero cuando todo el mundo piensa en un ingeniero informático

trabajando para una empresa, mucha gente se imagina un tipo como el antiguo
Paco, un friki obsesivo de la programación y del mundo de la informática.
Incluso me he tomado la licencia de exagerar más el personaje ficticio.
Cuando, en la realidad, existen montones de trabajos diferentes, y más de uno
de ellos no tiene que ver con programar o montar ordenadores (rompiendo
mitos: en donde trabajo si un ordenador se rompe, para arreglarlo jamás lo
tocamos nosotros, los programadores, lo tocan los de sistemas). Cuando
terminas una ingeniería informática o un módulo es verdad que si eres un gran
programador puedes resistir años en este negocio, pero tarde o temprano
(tanto si eres de modulo, como un ingeniero, como si vienes de un curso de
programación), algún día, puede que subas a los cargos más cercanos a la
Ingeniería del Software, y más lejanos a la programación, más lejanos a lo que
la gente suele considerar como informática.

Lo que he intentado con este texto es explicar la idea básica de la Ingeniería

del Software. La Ingeniería del Software es, en definitiva, planificar cómo se
va a programar una enorme aplicación, es poner reglas de codificación que los
programadores deben de cumplir y que a mucha gente no les gusta usar al
principio (ésas que Paco no cumplió), es hablar con clientes que, seguramente,
sólo puedan hablar contigo en inglés y es más que seguro que tengas que
intuir qué es lo que realmente quieren, y es saber en qué estado se debe de
quedar el proyecto para su etapa de mantenimiento, que es la etapa final.
Algo así como no dejar para mañana lo que puedas hacer hoy (aunque en
alguna que otra empresa esto no se cumpla porque haya que planificar al
mismo tiempo que se programa y hacerlo todo con prisas y horas extras etc
etc). Es duro, al principio, y puede que con una excesiva visión empresarial
que haga echarse atrás a más de un friki informático, pero, oye, es lo que
ayuda a que los programas más enormes se terminen haciendo.