Pages Menu
Categories Menu

Posted by on Oct 4, 2010 in buenas prácticas, errores y riesgos | 4 comments

Sobre vampiros, hombres lobo y si debería desarrollo poder acceder a producción

Históricamente, entre los diferentes grupos de personas que participan y son necesarias en el desarrollo, mantenimiento y explotación de un sistema de información, siempre ha habido marcadas idiosincrasias, culturas, diferentes costumbres, maneras de ver la vida, sanas (o no tanto) disputas, leyendas, ritos, etc. Ejemplos de ello pueden observarse entre, por ejemplo, comerciales y desarrolladores, desarrolladores y jefes de proyecto, clientes y comerciales, usuarios y desarrolladores, analistas y desarrolladores, etc. Si bien, de entre todos estos diferentes grupos y culturas, una de las más históricas y curiosas relaciones es la que une a desarrollo y explotación (o sistemas, producción, etc.), sobre la que trata este post, y que es una relación incluso tan antigua y curiosa como la que une a comerciales y desarrollo (que daría para otro post).

Todo esto viene porque hace unos días leí un curioso, y polémico, post en el blog de Coding Horror, que, además de traerme muchos recuerdos del día a día del desarrollo, comparaba a los desarrolladores con vampiros y al personal de sistemas con hombres lobos. Lo de la comparación viene de que, según el artículo, los programadores son como vampiros, con frecuencia viven en la noche, apenas toman el sol y suelen pensar que su código es inmortal. Y comparaba los administradores de sistemas con hombres lobo, porque pueden parecer normales, pero son invulnerables a cosas que matarían a la gente común y son propensos a extrañas transformaciones durante las noches, con la luna, sobre todo si hay apagones o se va la luz.

Aparte de la acertada o desacertada comparación, uno de los temas de fondo que se trataban era la (mala) práctica de que los desarrolladores software accedan a los sistemas de producción, aspecto sobre el que desarrollo y sistemas suelen tener sus diferencias. Normalmente a los desarrolladores les gusta acceder a producción y a sistemas no le gusta que lo hagan. Razones como las prisas por terminar un parche, en ocasiones evitar burocracia, poder probar en un entorno real, etc., hacen que a desarrollo le atraiga acceder a los sistemas. Y razones como la caída de un sistema en producción, que el software a instalar no sea del todo fiable, que no se sigan todos los procedimientos (como los script de marcha atrás en caso de fallo, etc.) hacen que sistemas no lo vea tan bien.

Personalmente pienso que todo depende. Depende del sistema, de su criticidad, del tamaño de la empresa, etc. Y que, salvo en empresas pequeñas, el acceso a producción desde desarrollo debiera ser más una excepción que una regla, ya que puede traer problemas muy serios. Además de los problemas que comentábamos antes, recuerdo que en varios departamentos de desarrollo en los que trabajé, por accesos no controlados a producción, no se sabia que versión tenía en producción cada cliente, ya que ciertos programadores instalaban directamente en explotación, sin avisar y sin guardar los fuentes del código instalado en el repositorio de versiones de desarrollo. Sería interesante tener más opiniones ¿Qué opináis? ¿Cómo lo lleváis vosotros en el día a día?

Javier Garzás

Javier Garzás

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.
Javier Garzás

4 Comments

  1. Buenas, yo creo que como has dicho, depende, ya que en empresas pequeñas no hay o no suele haber un ciclo formal en el que tras un desarrollo haya una revisión por dirección de proyectos, se documenten previamente los cambios que se harán en producción analizando los posibles problemas que esto pueda causar, fallas de seguridad, etc.

    Por ejemplo, si hay que cambiar el backcolor a una tabla en el HTML de la web de la empresa, pues lo sueles hacer en producción, ya que ahí la posibilidad de que un fallo produzca una catástrofe es prácticamente nula.

    Asi que lo veo como un depende, aunque en un 90 y pico por ciento de los casos apuesto que no se debe hacer.

    saludos!

  2. A ver, yo estoy de acuerdo que en el tema de procesos, la respuesta correcta casi siempre es «depende», pero hay temas que pueden ser muy serios.

    En el caso de empresas que tienen que cumplir con la SOX, el acceso «no controlado» a producción puede ser considerado un delito, sobretodo si los cambios implican publicar información oficial de la empresa.

    Sin embargo, creo que es más valioso si lo vemos como uno de esos casos en los que puede hacerse el ejercicio de entender, ¿qué parte del proceso de liberación y control de cambios en producción es esencial? y ¿qué valor le añade al cliente / equipo / organización?.

    Saludos!

  3. Llego un poco tarde a este hilo, pero por si acaso alguien lo lee como yo, unos meses más tarde, quería añadir mi propia experiencia. No soy programador «oficial» pero si «oficioso» y mi misión en la Administración en la que trabajo tiene que ver con dirigir el abultado/escaso (depende de quien lo diga) presupuesto para desarrollos informáticos.

    Por mi propia experiencia puedo entender la debilidad humana: fallo tonto en el modulito que acabo de hacer y la vergüenza torera de ver cómo se demorará la corrección horas o incluso días en «ponerlo en producción». Mientras tanto el usuario/a esperando con el hacha en la mano porque a su vez tiene a los administrados usuario/as de la página web esperando cabreados a que el formulario web funcione y puedan pedir la subvención «por este maravilloso nuevo sistema que me evita colas y poder hacerlo a las 10 de la noche en casita».
    Otras veces, lo que oigo y de lo que me asombro por su posible parte de verdad es «no consigo reproducir el error que me reportas en desarrollo», o «el entorno de desarrollo es inestable o diferente a producción», «no tengo seguridad de que cuando lo pase a producción funcione exactamente como lo hemos programado»…un largo etcétera de explicaciones que lo único que me conducen a pensar, como propiedad o «pagador» del software es en lo poco profesionalizado (en el sentido de garantías 100%) que está en los grandes entornos que conozco. Y ahí comienzan las soluciones rápidas de andar por casa: «pásame tu password e intento reproducirlo pero yo no te lo he pedido porque se me cae el pelo», «voy a poner unas trazas…y vuelves a probar para ver donde casca a ver si lo vamos pillando»…

    Desde el punto de vista de quien contrata esos servicios y está controlándolos desde muy cerca, no salgo de mi asombro ante la pérdida de tiempo y dinero de todos estos procesos de recuperación de errores y las dificultades del entorno de desarrollo.

    Ignoro mucho de este mundo, pero, pero, pero…¿no hay nada establecido ya, probado, muy probado, para acercar ambos mundos, desarrollo y producción? Separarlos drásticamente puede evitar errores gravísimos, pero el cliente final no acaba de entender luego lo disparatado de los costes.

    Felicidades por tu blog Javier, con temas muy interesantes de los que estoy aprendiendo mucho y que difundo entre desarrolladores de software (aunque no sé si harán mucho caso a alguien que no es de su clan, jeje).

  4. @José Félix Crego: Gracias José Félix, y muy bueno tu comentario, detalla fielmente el «duro y despilfarrante» día a día de muchas organizaciones…

Post a Reply

Tu dirección de correo electrónico no será publicada.

Share This