Ah, las reuniones familiares, donde aparecen esos personajes a veces nefastos que casi nos habíamos olvidado. En el desarrollo de software también tenemos de estos encuentros, en donde se juntan elementos poco felices para arruinarnos el día.
A continuación les dejo un retrato bastante repulsivo de patologías casi universales en Sistemas. Por favor, intenten no seguir leyendo mientras almuerzan. Estan avisados.
La Arquitectura del Presupuesto
Alguna vez todos fuimos afectados por el efecto de la Arquitectura del Prespuesto. Esto ocurre cuando se tiran por la ventana tecnologías que son obvias y necesarias, en favor de una reducción de costos. La conversación en general viene así:
"¿Realmente, absolutamente, completamente necesitás a X?", pregunta el sponsor del proyecto.
En el lugar de "X" ubiquen cualquier cosa de vital importancia para el proyecto: licencias de software, servers redundantes, backups fuera de oficina, sistema de alimentación de energía, etc. Siempre escuhamos esta pregunta en un tono paternal, como si un mayor nos hubiera agarrado gastando todo el dinero en comics y golosinas, mientras que estos adultos serios intentan seguir comprando más valijas para seguir guardando todas las ganancias.
La respuesta correta es "Si. Lo necesitamos". Y generalmente no es lo que respondemos.
Después de todo, somos ingenieros, y la ingeniería es el arte de elegir el mal menor, de realizar consesiones para obtener una solución viable. Todos sabemos que realmente no necesitamos esas extravagancias como un generador de energía, siempre y cuando tengamos suficientes de esas rueditas de hamster y un equipo de internos corriendo en el data center. Por lo tanto, en vez de decir "Si. Lo necesitamos" elaboramos una respuesta como "Bueno, podríamos seguir sin un segundo servidor, siempre y cuando pueda aceptar baja disponibilidad por tareas de mantenimiento rutinarias, y cuando un chip de RAM sea afectado por algún rayo cósmico y cambie el valor de un bit, provocando una falla, pero si compramos memorias con control de paridad podríamos zafar de eso, por lo cual sólo nos tendriamos que preocupar por las caidas del sistema operativo, las que ocurren cada tres-punto-nueve días, por lo que tendríamos que establecer un régimen de reinicios nocturnos, que podría ser llevado a cabo por los internos cuando se toman un descanso de las ruedas de hamster para generar energía".
Todo lo cual puede ser completamente cierto, pero es lo absolutamente peor para decir. El sponsor seguro que apagó el cerebro luego de que dijimos "Bueno..."
El problema reside en ver nuestra parte como el rol de ingeniero, mientras que para el sponsor se había iniciado una negociación. Y en una negociación, lo último que se quiere hacer es realizar conseciones a la primera demanda. De hecho, la respuesta correcta a la pregunta "¿realmente lo necesitamos?" es algo como esto:
"Sin un segundo servidor, todo el sistema va a caerse al menos tres veces al día, particularmente cuando esté bajo carga o cuando usted esté realizando la demo a la Junta de Directores. De hecho, en realidad necesitamos cuatro servidores de manera de poder realizar mantenimiento de forma independiente en cualquier momento y aún mantenernos al 100% de nuestra capacidad, incluso en el caso de una falla inesperada en un par de servidores".
Por supuesto, ambos sabemos que en realidad no necesitamos un tercer y cuarto servidor. Es tan solo un truco para cambiarle el tema al sponsor. Estamos cambiando la apuesta, mostrando que en realidad estamos funcionando con lo indispensable, peligrosamente cerca de la configuración mínima tolerable. Y además, si encima llegamos a obtener estos servidores extra, seguro que se vamos a poder utilizar un servidor para que el entorno de QA sea igual al productivo, y el servidor extra puede resultar un buen equipo de integración continua.
La planificación desplanificada
Otra situación en la que nos lastimamos solos es en los cambios en la planificación. Estadísticamente hablando, es más probable que consigamos reproducir las estrofas base de "La Bamba" usando un par de neutrones cósmicos que completar el proyecto en tiempo. Tarde o temprano nos daremos cuanta que la única forma de entregar el proyecto a tiempo y bajo el presupuesto asignado es reducir su alcance al de un "Hola mundo".
Cuando ocurre esto, y por ser desarrolladores responsables, debemos informarle al sponsor que hay atrasos en la planificación. Quizás no nos demos cuenta, pero al decir esto estamos lanzando la señal internacional de debilidad en negociaciones.
Tu sponsor, que tiene una reputación (y presupuesto) que mantener, va a responder con "Podemos cambiar la fecha, pero ya que retrasamos la entrega, podríamos también incluir estas funcionalidades extra".
El proyecto ya está atrasado. Añadir más funciones seguro que lo va a atrasar aún más, en especial ahora que vemos que el equipo no avanza tan rápido como se esperaba. Entonces, ¿qué mente perversa involucrada en el éxito del proyecto podría querer incrementar el daño al aumentar el alcance?
Mi única recomendación es mostrar información real. Exponer los gráficos de avance, mostrando realísticamente cuándo se podría obtener la funcionalidad originalmente pactada. Luego mostrar cómo el hecho de estar atrasados y el aumento en el alcance pondrían una fecha de entrega lejana. Tan lejana como para preocuparnos por la extinción del sol antes de llegar a una beta.
La falacia del capital
Cuando algo es muy caro, queremos usarlo todo el tiempo, sin importar qué tan util nos resulte.
Este concepto es justo el inverso al de Aquitectura de Capital. Por ejemplo, las bases de datos suelen costar casi lo mismo que un crucero de guerra. Por lo tanto, a todos los jefes se les mete en la cabeza que todo necesita estar en LA base de datos. Singular. Como en "una".
Bueno, si un único servidor de base de datos es la fuente de toda la verdad, va a ser mejor que seamos muy cuidadosos con el amigo. Y la mejor forma de ser cuidadosos es asegurarnos que nadie, nadie, nadie jamás la toque. Así creamos un equipo de personas con mentes jóvenes y maleables con tendencias obsesivo-compulsivas hacia las abreviaturas, y los nombramos Jerarcas de la Verdad.
Pero, como esa bendita base costó tanto, necesitamos justificar todo ese dinero. Entonces obligamos a que todas las aplicaciones tengan que almacenar sus datos en La Base De Datos. Sin importar que nadie sepa dónde está, cómo funciona o si realmente existe.
(siéntase libre de reemplazar La Base De Datos por cualquier fetiche al que hayan tirado todo su dinero: un mainframe, WebSphere, AquaLogic, etc).
Por supuesto, si las bases de datos no fueran tan costosas, a nadie le importaría cuántas de ellas estarían dando vueltas. Por esto es que MySQL, Postgres, SQLite y otras son realmente útiles. No hay problema en crear muchas instancias de bases de datos gratis. De hecho, finalmente podemos dejar que las unidades de negocio crezcan con independencia. Los servicios independientes pueden tener sus propios repositorios de datos, y no permitir a nadie de afuera que meta los dedos.
(Traducido de Budgetecture and it's ugly cousins)