La Ingeniería del Software y la táctica militar son temas apasionantes… y bastante similares. En ambos tienes que llevar adelante un proyecto (ataque, programa) contando con ciertos recursos.

En ambos temas ha habido una evolución considerable y curiosamente pareja. Esta es una visión superficial de la evolución pareja de ambas disciplinas.

Primeros enfrentamientos
Antiguamente la forma de combatir era bastante caótica, parecida a los comienzos de la programación. Simplemente un grupo de gente se juntaba y se ponían a atacar al enemigo. Con mayor o menor fortuna, pero poca previsión. Un buen ejemplo serían las tribus germánicas o galas, que borrachos y drogados cargaban de manera caótica con el enemigo para aplastarlo por mera fuerza bruta.

Su equivalente en la Ingeniería del Software sería esa época donde cualquiera podía hacer un programa, poca gente controlaba del tema y a los clientes se les podía llegar a cobrar una gran cantidad por tareas menores. El cliente no estaba formado para tratar con la informática.

Evolución del pensamiento militar
Con el tiempo, las civilizaciones que estudiaron el arte de la guerra y se organizaron, prevalecieron sobre las desorganizadas. Una unidad militar entrenada, con experiencia en combate era más efectiva que los bárbaros. Un ejemplo cercano son las legiones romanas, que con ejércitos inferiores en número derrotaron a los Galos y otras tribus germánicas. Otro ejemplo más actual (gracias a la película de los 300) serían los Espartanos, militares profesionales versus los Persas, ejército gigantesco con muy poca preparación, la mayoría esclavos.

El equivalente en Ingeniería del Software, serían expertos desarrolladores, a los que realmente les gusta programar y no es solo un trabajo. Imaginad a mediados de los 90 varias personas expertas en Java, sin formación específica pero que han investigado por su cuenta y están bien enterados de cómo hacer las cosas. Esos programadores expertos harán un producto de calidad, organizándose ellos mismos. El problema suele ser encontrar a esa gente buena.

Guerra Total
Hasta la Primera Guerra Mundial, las guerras fueron siempre limitadas. Pero en la Gran Guerra se hizo una leva masiva. Casi todo el país iba a combatir al malvado enemigo. Pero ya antes los militares habían descubierto que la única manera que fueran efectivos una gran cantidad de soldados de leva recién reclutados era una estricta organización dirigida por militares formados en academias especiales. Toda la estructura era jerárquica, muy bien definida:

- Estado Mayor del Ejército:Dirigido por un militar de alta graduación, era el encargado de dirigir el esfuerzo de guerra.
- Grupo de Ejércitos: Formado por varios Ejércitos.
- Ejército: Dirigidos por un Capitán General o similar. Cada ejército solía tener 5-6 divisiones.
- Cuerpo de Ejército/División: Los Ejércitos estaban divididos en Divisiones, dirigidas por un General de División y a veces se agrupaban en cuerpos de 2-3 Divisiones, dirigidos por un Teniente General. Cada División solía tener entre 20.000 y 30.000 hombres.
- Y más: Cada División se dividia en Brigadas (General de Brigada), Cada Brigada se divide en regimientos, llevados por coroneles. Los regimientos en Batallones (Teniente Coronel), los Batallones en Compañías (Capitán), cada Compañía se dividía en Pelotones (Tenientes), cada Pelotón en Escuadras (Sargento) y cada Escuadra incluso en binómios de dos personas.

Organización de una División Soviética de Fusileros en la 2ª Guerra Mundial en 1941. (Pulsa para ampliar)

Evidentemente esto dependía de cada país y cada momento, pero nos da una idea aproximada de la gran estructura organizativa que existia para llevar adelante una guerra. La obediencia era obligatoria y si desobedecías serias juzgado o incluso podias ser ejecutado por tu mando (Ejecución Sumaria). Todo muy reglado y muy organizado.

Esto era mil veces mejor que el ejército Persa, formado por más de un millón de hombres, pero desorganizado y proclive a retirarse por motivos de moral.

El equivalente en Ingeniería del Software son las pesadas planificaciones para los programas en Cobol de toda la vida, con sus cuadernos de carga, sus analistas orgánicos, analistas funcionales, jefes de proyecto, carga de datos, casos de prueba, metodología Warnier, Jackson, etc…

La metodología pesada era mil veces mejor que un montón de gente desorganizada programando, ya que es imposible conseguir un gran número de expertos y tocaba lidiar con programadores con conocimientos y experiencia limitadas.

Problemas de la jerarquía estricta
Pero ambos modelos tenían un problema, su excesiva rigidez. Esto llevaba a las terribles matanzas que todos conocéis con miles de soldados avanzando suicidamente contra una trinchera enemiga llena de ametralladoras, ordenado por un General que nunca había visto el campo de batalla y secundado por oficiales. En la cadena de mando había gente que seguía la estupidez y gente que se veia forzada a seguirla. Al final el soldado tenia que avanzar para morir o retroceder para ser disparado por sus oficiales o juzgado por cobardía (ejecución).

Efectos de un ataque absurdo

Y que os voy a contar en Ingeniería del Software: Plazos imposibles, elecciones absurdas de tecnología, horas extras a mansalva por motivos ilógicos, seguimiento ciego de metodologías incorrectas donde el método causa más problemas en vez de ser una ayuda para resolverlos, decisiones tomadas por personas sin conocimientos técnicos adecuados, etc…

Resolver este problema
Y todo este rollo para que? para explicar como algunos decidieron resolver este problema, tanto militares como ingenieros.

Los militares Alemanes solventaron este problema en el periodo de entreguerras. Gracias a militares como Guderian, Manstein, Rommel, se hizo al ejército más ágil. Los suboficiales y oficiales tenian mucha más iniciativa y libertad para ejecutarla. Eran formados en las academias para actuar. Así una orden del alto mando errónea, dada por un general que no veia el campo de batalla, no tenia tantas consecuencias. De hecho TODA la cadena de mando estaba formada en este sentido. Las ordenes de un general decian QUE hacer, pero no COMO hacerlo, al contrario que hacían otros ejércitos que seguían con las viejas tradiciones. Esta forma de pensar requería de militares muy bien formados y especialmente muy bien formados en esta manera particular de pensar.

Todo esto no fue sin oposición, ya que muchos generales de la vieja escuela, de los de “con el Kaiser esto no pasaba” y “los tanques no valen para nada, la aviación tampoco, el arma más importante es la caballería” hicieron de todo para dinamitar los esfuerzos de estos brillantes militares Alemanes.

Y la guerra fue muy bien para los Alemanes, derrotaron e invadieron a Francia, Polonia, Noruega, Bélgica, Holanda, Yugoslavia, Grecia…

Pero todo se vio truncado por gente inutil de alto nivel, como el responsable de las Fuerzas Aéreas (Göering) que hizo que Alemania no pudiera derrotar a Gran Bretaña, como Mussolini, que solo metió en lios a los Alemanes y por el propio Hitler, que invadió la URSS y sobretodo se dedicó a microcontrolar las unidades Alemanas en el frente… acabando con todo lo bueno que estos generales Alemanes habían desarrollado, acabando con la iniciativa personal y la libertad de acción.

En la Ingeniería del Software pasa algo parecido, pero en escala más pequeña. Hoy en día existen ciertas herramientas y metodologías modernas:
- RUP
- XP
- Patrones de diseño y Arquitectura
- Antipatrones
- ITIL/CMMI

Pero fallan muchas cosas:

- Poca gente está bien formada y conoce estas metodologías.

- La formación que se tiene es insuficiente. La gente que viene por cursillos y masters suelen tener una visión muy limitada, ya que normalmente no son ni informáticos. Los universitarios están en teoría mejor formados… pero realmente en las universidades suerte tiene el que ve algo por encima de POO y en cambio se malgasta tiempo en Cobol, ADA y demás chorradas en vez de empezar programando en C y Java desde el principio. Al final todo el mundo que sabe, es porque aprende por su cuenta.

-Es difícil encontrar a esa gente buena. Y jefes buenos muchos menos. La mayoría de jefes son de la “vieja era”. Cualquier cambio se ve como “los tanques no valen para nada, viva la caballería”.

- Si tienes suerte y tienes gente buena, los jefes no te dejarán un buen presupuesto para formar un equipo de trabajo estable y duradero. No entienden la diferencia entre programar bien y programar mal.

- Si un jefe atisba diferencias entre programar bien y programar mal, por algún extraño motivo le gustará más la forma mala de hacerlo. Rápido, con pocos recursos, para ya… creyendo que así consigue algún objetivo estratégico o muestra su capacidad de liderazgo.

Lema: “Hacer algo rápido y chapuza parece más rápido, pero NUNCA lo es”

Conclusión
Como véis, los problemas son comunes entre ambas disciplinas. Siempre existe un temor al cambio y una persona desconocedora del aspecto técnico lastrará cualquier proyecto… cuanto más arriba esté más.

Abundan los jefes que no dudarán en lanzar un proyecto a morir con exigencias absurdas…

This entry was posted on Viernes, Mayo 25th, 2007 at 11:22 am and is filed under Historia, Programación. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.