Algo pasa con la ingeniería del software

Desde que me dedico a esto de la construcción (de software) siempre he envidiado a los otros constructores, los que hacen edificios, presas, carreteras o cualquier otra cosa física. Sean arquitectos, ingenieros de caminos o de obras públicas, todo el mundo tiene claro cómo se hacen las cosas en esas profesiones. Se sabe quien diseña, quien se hace cargo de los problemas estructurales y la forma en que se reparte el trabajo y la responsabilidad.

Visto desde el punto de vista de un ingeniero licenciado en informática solo puedo decir que la ingeniería que se aplica en nuestro gremio es como una top-model, deseada por todos y totalmente inalcanzable para la mayoría. Hay varios hechos que he constatado durante mis años de experiencia que hacen de éste un hecho irrefutable, no solo en España sino en el resto del mundo. Veamos algunos:

    1. No existe una metodología comúnmente adoptada ni que sea posible adaptarla a todas las necesidades de programación o a todos los lenguajes/entornos de manera sencilla.
    2. Las necesidades de cambios constantes en el software, junto con un ttm (time to market) más reducido cada vez hace que cualquier procedimiento que retrase el resultado sea imposible de aplicar, o cuando se aplica solo sirve para hacer fracasar el proyecto
    3. La poca preparación de los gestores, o incluso la creencia de que cualquiera puede dirigir un proyecto de software hace que, incluso con profesionales cualificados en el equipo, el proyecto no use enfoques de ingeniería.
    4. La falta de regulación profesional y de, entre otras cosas, un colegio oficial, hace muy complicado hacer que normas de desarrollo se estandaricen o se hagan “oficiales”


    Aunque hay muchos más motivos (obviando la estupidez humana y la falta de recursos) intentaré describir cada uno de los puntos anteriores según mi experiencia profesional.

    La metodología

    A nadie se le ocurriría construir un edificio de 15 plantas sin tener planos, ni un estudio de materiales, ni un estudio del suelo, etc. Todas estas cosas son obligatorias por ley o están derivadas de lo que se entiende como un proyecto de arquitectura. Para realizar cada una de estas actividades los arquitectos y/o ingenieros disponen de métodos aprobados y fiables. Se actualizan, se mejoran, pero siempre están ahí y cualquier arquitecto/ingeniero los debe conocer.

    En informática eso no es así, no es obligatorio el uso de “planos” para el diseño, o al menos se acepta cualquier tipo de planos y, lo que es peor, estos se cambian sobre la marcha sin ningún pudor. No es nada sorprendente que el cliente, tras ver el resultado de lo que pidió inicialmente exija que se rehaga todo porque no se parece a lo que tenía en mente. ¿Alguien se imagina que tras construir un chalet el cliente pida que le pongan 5 plantas más y un helipuerto en la azotea? Seguro que el arquitecto se mea de la risa, pero es que el jefe de obra le va a decir que esos son los planos que él tiene que construir y que cualquier otra cosa la hable con el arquitecto. ¿Por qué aquí no?

    Los cambios constantes

    El ejemplo anterior de cambio, inspirado por uno de mis últimos trabajos en los que tuvimos que hacer un sitio web completo cuando lo que estaba ofertado era un sistema de búsqueda y localización de documentos, es una muestra de a lo que lleva el no tener un método que exija una aprobación del cliente de manera que este tenga unos “planos” sobre los que saber qué está pagando y el constructor qué es lo que está haciendo. Pero hay otros cambios, que son inevitables, asociados a la naturaleza misma del software. Estos cambios no son fruto de mala comunicación ni de falta de método, simplemente sucede que algunas cosas se quedan obsoletas antes de terminar el desarrollo.

    Cuando la vida de ciertas tecnologías es muy breve, o cuando la construcción de software se basa en paradigmas “con fecha de caducidad” el diseñador se siente tentado de utilizar la última versión de la última tecnología, aún no asentada, de manera que pueda tener más tiempo de vida. (Voy a usar Java 6 con la beta de xxx y el nuevo yyy, así me evito tener que cambiar después)… Craso error, cuando sacamos a producción el producto, las versiones de todas las tecnologías han aumentado, la compatibilidad no es buena y el soporte para las versiones que elegimos está terminando… Así no hay manera. Esto es resultado de la política de algunos productores de software de “Disparar y avanzar“, que consiste en sacar nuevas tecnologías (refritos con nombres nuevos) para ganar tiempo sobre los seguidores que lo perderán intentando ser “compatibles” o adoptar esas tecnologías.

    Aún eligiendo la plataforma correcta y teniendo tiempos de desarrollo compatibles con el mantenimiento de las mismas, los requisitos de los clientes son, por naturaleza, dependientes de su negocio. Como el negocio, hoy en día, sufre variaciones importantes que obligan a adaptarse a las empresas, el software que da soporte al negocio en esas empresas ha de adaptarse, el TTM (time to market) de los desarrollos software ha de hacerse más breve cada vez. Esto trae interesantes consecuencias:

    • Menos tiempo para la toma de requisitos y requisitos más breves, aunque se cuenta con la ayuda del “requisito diferencial” que consiste en, sólamente, tomar los requisitos que cambian y no los que permanecen.
    • Menos tiempo para diseño, generalmente se reutiliza el diseño ya en ejecución y se “parchea” suponiendo que el diseño general es correcto.
    • Casi nada para la implantación, o bien se toma tiempo prestado al diseño, codificando según se escribe el mismo o se utilizan plataformas de implantación rápida (php, RoR, etc) que ceden parte del control y de lo que se puede y no se puede hacer a un framework a cambio de un desarrollo más breve.
    • Pruebas ¿qué pruebas? generalmente se realizan a la vez que las sesiones de aceptación del cliente, el único requisito es que haya pasado algún tipo de prueba unitaria.
    • Usar y re-tirar. Una vez todo en marcha el circulo se vuelve a cerrar ya que la vida de este desarrollo será mínima y gran parte de la porquería que hemos generado tendremos que reutilizarla para el próximo ciclo.
    • Documentación, ese gran desconocido. El esfuerzo a dedicar a la documentación se reduce drásticamente (siempre se ha considerado que debe ser una fracción del dedicado al resto de actividades), con lo que, a veces, se reutilizan documentos de requisitos para describir la arquitectura y manuales de usuario como descripciones funcionales.

    Total, que al final nos quedamos convertidos en un equipo de bomberos que no hacen más que apagar fuegos aquí y allá. La diferencia entre un equipo competente y uno que no es la misma que entre los bomberos profesionales y la cuadrilla de campo… Unos lo hacen todos los días y los otros solo cuando les arde la casa del vecino. Pero ¿alguien ve la diferencia entre construir y apagar?… Muchos clientes no.

    Los gestores

    Quizá en este apartado me toque echar piedras sobre mi tejado, pero yo me presento a mi mismo como un técnico (tecnólogo) que se ve obligado a hacer labores de gestión para sacar un proyecto adelante… Se supone que debería haber gente preparada exclusivamente en tareas de gestión que pudiesen sacar adelante cualquier proyecto, sea de ingeniería, de arquitectura o la gala del carnaval de tenerife… Vamos, el “señor lobo” de pulp fiction. La realidad es que, realmente, el señor lobo no es tan eficaz como parece. El gestor de un proyecto software (según una experiencia reciente) se limita a:

    • Decirte lo lento que vas y enviarte modificaciones sin sentido para que te retrases más.
    • Recordarte que él es el que tiene que hablar con el cliente para, acto seguido, pasarte su teléfono para que le respondas unas dudas “técnicas”.
    • Olvidarse de revisar el trabajo hasta que no recibe una llamada del cliente quejándose por lo que ha recibido y, claro, luego hay que rehacerlo todo por la incompetencia del resto del equipo.
    • Ponerse las medallas ante el cliente, ante el equipo y ante Dios padre. Asegurar que el próximo proyecto lo hará con un equipo mejor y por menos dinero y hacer creer al cliente que la culpa de todo es suya, aunque se hará un esfuerzo para cumplir con sus irracionales peticiones en forma y plazo. (no se como se pueden hacer cuatro proyectos distintos con el presupuesto de uno solo que nada tenía que ver).

    ¿Alguien ve aquí algo útil? Yo tampoco. Sin embargo este es el perfil medio del “gerente” de empresa de software (luego está el que vende kilos de carne a tanto la hora, pero esos son otra historia). Esto es así porque en las empresas se sigue el principio de “si eres bueno en lo que haces, nunca ascenderás” y, por tanto, solo ascienden los que no son buenos técnicos ni buenos comerciales (eso si, saben usar muy bien el forwared en el correo electrónico).

    La falta de regulación profesional

    Aunque aquí hay mucha gente que no está de acuerdo y que postula por la no existencia de colegios profesionales, lo cierto es que la responsabilidad de los proyectos software debería estar en manos de algún técnico preparado y llevar una firma última a la que exigir cuentas si algo no va. Si una casa se derrumba por estar mal el proyecto, es muy sencillo saber quien hizo los planos y a quién se le contrató la construcción. En el caso de la informática no. Nadie rinde cuentas, nadie sabe de quién es un diseño, nadie sabe de quien es la responsabilidad de un cuelgue que ha provocado pérdidas inmensas o incluso pérdida de vidas.

    La existencia de un colegio profesional de informáticos permitiría que, aún a costa de unas tasas, se siguieran unas mínimas normas para poder desarrollar un proyecto de software (al menos aquellos que tengan cierta envergadura o se contrate con la administración). Se evitaría mucho intrusismo y se fomentaría algún tipo de estándar para la creación de proyectos (al menos los que firmen colegiados) y estaría mucho más regulado el precio de estos servicios.

    ¿Alguien se imagina que a mi (ingeniero licenciado informático) se me permitiera firmar los planos de un rascacielos… ¿pues porqué un físico si puede decir que es el jefe de proyecto de un sistema de mantenimiento de historiales clínicos para un hospital?

    En fin… Me dejo un montón de problemas más, espero que me ayudeis a dejar constancia de ellos con vuestros comentarios.