El software no es sólo desarrollo

Supongo que con este título no estoy diciendo nada nuevo, sin embargo, el día a día nos dice otra cosa. Tan importante es desarrollar un software de calidad como su mantenimiento o explotación, de hecho, la experiencia nos dice que cuanto mejor hagamos el trabajo al principio más fácil y cómodamente abordaremos las etapas futuras.

Hablamos siempre de lo importante que es documentar, definir pruebas, refinar nuestras metodologías, definir buenas prácticas, especialización de los recursos y otras miles de cosas, pero todas ellas afectan -en gran medida- el equipo de desarrollo. ¿Y qué pasa con el resto de perfiles que interviene el ciclo de vida del software? ¿Qué pasa con los administradores de bases de datos y/o administradores de sistemas? ¿Cómo es nuestra relación con ellos? ¿Qué herramientas y procedimientos compartimos con ellos? Dentro del equipo de desarrollo hay “cosas” que comienzan a madurar y síntoma de ello es que a veces nos preguntamos, ¿Qué haríamos sin…?

En este post os hablaré concrétamente de Maven e Hibernate. En mi entorno profesional, estas dos herramientas son muy frecuentes y ambas tienen mucho que decir sobre la relación del equipo de desarrollo y el resto de perfiles que normalmente pertenecen al departamento de sistemas.

Desde hace tiempo la elaboración de libros blancos de buenas prácticas se ha convertido en una moda. En un próximo post daré mi opinión al respecto (“La parte oscura de los libros blancos”), pero por ahora sólo hago referencia porque son precisamente estos libros blancos los que indican/recomiendan/exigen el uso de herramientas como Maven e Hibernate. De qué vale que el equipo de desarrollo haga uso de este tipo de herramientas si luego nos encontramos con situaciones como estas:

  • El despliegue del software lo lleva a cabo el propio departamento de sistemas y allí reina su propio libro blanco de buenas prácticas. Si nuestro proyecto está modelado con Maven, y contamos con un ecosistema software mínimamente definido, ¿Por qué tenemos que entregar un WAR con la aplicación que posteriormente descomprimen para configurar (base de datos, LDAP, SMTP, etc)? ¿Por qué los administradores de sistemas no usan Maven? Se podrían beneficiar de muchas cosas como por ejemplo los perfiles para los distintos entornos de despliegue, ejecución de pruebas que no pueden faltar y un largo etcetera. Creo que sería genial que tanto el equipo de desarrollo como el departamento de sistemas compartiesen el uso de Maven. Evidentemente, cada uno desde su perspectiva.
  • ¿Por qué debemos entregar al DBA los script de creación de esquemas cuando de eso se encarga automáticamente hibernate? Recientemente preparamos para un proyecto un módulo con una interfaz de línea de comandos con varias finalidades, crear el esquema de base de datos, creación de sinónimos y carga inicial de información (tablas maestras). Con un módulo de estas características, el proceso de instalación como podéis imaginar queda resumido en ejecutar un par de sentencias desde la línea de comandos. Pues parece que esto no entraba dentro del libro blanco del departamento de sistemas.

Estos son sólo dos ejemplos que ponen de manifiesto que el equipo de desarrollo y el departamento de sistemas deben tener un único libro blanco de buenas prácticas y que existe una brecha que debe estrecharse cuanto antes.

En varias ocasiones he tenido oportunidad de charlar con responsables de departamentos de sistemas y una de sus preocupaciones es que los equipos de desarrollo les entregan software que una vez puesto en producción comienza a dar problemas. ¿Qué pasa en esta situación? Al igual que existen pruebas unitarias y funcionales, el departamento de sistemas puede disponer de pruebas de integración y sistemas que proporcionen unos indicadores para garantizar unos mínimos. No sería la primera vez que se pone en producción una aplicación con la configuración por defecto del pool C3P0 muy usado con Hibernate. Luego vienen las sorpresas. ¿Cómo comprueban los DBAs que las tablas de un sistema de información comienzan con un determinado prefijo? ¿Mirando los scripts? ¿No sería más fácil con un plugin de Maven?

Una vez más, la comunicación entre los distintos perfiles es fundamental para que el ciclo de vida de un software funcione.

6 thoughts on “El software no es sólo desarrollo

  1. Saludos Manuel,

    Sin duda que un proceso de desarrollo no es simplemente el “equipo de desarrollo”. No se como trabajais en tu empresa la verdad ni si considerais parte del equipo de desarrollo gente como los diseñadores gráficos o quien realice las interacciones Ajax por poner un par de ejemplos básicos (o si son programadores esta gente también), pero este es otro de los puntos que creo que la palabra clave es COMUNICACIÓN.

    Puedo asegurarte que si antes de lanzar los scripts a Sistemas (o en nuestro caso los planes de prueba del departamento de Testing, …) hablas con ellos sobre el tema, se lo propones, se discute, … ahorrarás el 90% de estos quebradores.

    El tema de los DBA que comentas me parece bastante interesante, en nuestro caso al final también pasa por trabajar codo con codo con ellos en cuanto a las optimizaciones de las consultas, diseño de vistas, … aunque es verdad que sus cambios afectan de forma bastante “interna” al equipo de desarrollo. Yo también me he visto en muchos casos mareado por necesidades de DBA´s.

    Un saludo y buen blog !

    Un saludo

  2. Hola Javier:

    En nuestra área de desarrollo hay perfiles para esas cosas que comentas, desde un diseñador gráfico hasta un UI Developer pasando por un QA. La situación que describo está relacionada precisamente cuando nuestro trabajo se ve afectado por esos libros blancos donde el cliente tiene departamentos (desarrollo, sistemas) que entre ellos no hablan lo suficiente.

    Un saludo

  3. Buenas Manuel,

    El problema que le veo a esos “libros” es que generalmente suelen quedar relegados en algún punto oscuro del gestor documental empresarial, no mantenidos como se merecen y son muy propensos a la desinformación ya que todo el que entre nuevo debería conocerlo, debería saber como “meterle mano”, …

    Me recuerda un poco a las normativas de codificación y estilo en los lenguajes de programación.
    En fin, desde que incorporas y configuras CheckStyle y/o FindBugs en tu IDE favorito y lo cuelgas en un servidor web accesible por todos los desarrolladores, piensas: por qué la hice ? (yo la hice :( jeje).

    Una proposición que yo haría a tu sistema es mantener toda esta información en un formato que pueda considerarse amigable al cambio, por ejemplo un wiki (aunque entiendo que esto pueda parecer “poco formal”). En la situación de que debas tratar con departamentos de Sistemas del cliente, habría que ver la disponibilidad de su departamento para compartir ese conocimiento del que hablas. En este caso no creo que exista una fórmula mágica, máxime teniendo en cuenta que quien paga tiene “la razón”, así que cada cliente puede hacer que tus normativas sean un mundo de heteogéneas. En cualquier caso, si puede ser una buena idea el realizar esos “libros blancos” que comentas compartidos de algún modo para evitar problemas en los momentos de entregas, despliegues, …

    Un saludo !

  4. Pingback: Qué aporta Clinker a devops? « klicap – ingeniería del puzle

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>