El arte de la guerra aplicado al desarrollo de software

Si trabajas en la industria del software, es probable que hayas oído hablar del paradigma de diseño divide y vencerás , que básicamente consiste en dividir recursivamente un problema en dos o más subproblemas ( divide ), hasta que estos se vuelvan lo suficientemente simples como para ser resueltos directamente. ( conquistar ).

Lo que quizás no sepa es que este paradigma se origina en una antigua estrategia política (el nombre se deriva del dicho latino divide et impera ) que sugiere que es posible mantener el control sobre los subordinados o súbditos fomentando la disidencia entre ellos.

Esta estrategia ha sido utilizada por innumerables políticos y líderes militares a lo largo de la historia, como Julio César (quien la usó durante las Guerras de las Galias para derrotar a los galos militarmente fuertes) y Napoleón (el experto en artillería francés dividía las tropas enemigas para que ninguna porción fuera más fuerte). que sus propias tropas, y luego interrumpir sus comunicaciones, impidiendo los esfuerzos del enemigo para coordinar y ejecutar ataques).

El arte de la guerra: principios antiguos aplicados al desarrollo

Sin embargo, la regla del divide y vencerás no es la única estrategia política que se puede aplicar al desarrollo de software. Aunque la política y la guerra tienen poco que ver con el desarrollo de software, al igual que los políticos y los generales, los desarrolladores deben liderar a sus subordinados, coordinar esfuerzos entre equipos, encontrar las mejores estrategias para resolver problemas y administrar recursos.

El arte de la guerra es un antiguo tratado militar escrito en el siglo V a. C. y atribuido a Sun Tzu, un antiguo estratega militar chino, cuyas teorías tuvieron una profunda influencia en la filosofía oriental y occidental.

A pesar de su antigüedad, el texto todavía se incluye en el plan de estudios de muchas escuelas militares en el este de Asia y figura como lectura recomendada en algunas academias militares en Occidente. El texto está dividido en 13 capítulos, cada uno dedicado a un aspecto diferente de la guerra.

Sin embargo, además de la guerra, los principios y las enseñanzas de Sun Tzu tienen aplicaciones prácticas en la política, los negocios, los deportes y, créalo o no, en el desarrollo de software. De hecho, es posible que esté aplicando algunos de estos principios en su rutina diaria, sin siquiera conocer sus orígenes.

A continuación, encontrará una breve lista de tácticas básicas y consejos explicados en el Arte de la Guerra. Probablemente se puedan aplicar a su trabajo en la industria del software o en cualquier otra industria.

El tiempo es crucial en cualquier campaña

Capítulo II, párrafo 2

Cuando te involucras en una lucha real, si la victoria tarda en llegar, entonces las armas de los hombres se desafilarán y su ardor se apagará.

Este principio se puede aplicar al desarrollo de software, como una regla que describe la relación entre la duración de los ciclos de desarrollo y la moral del desarrollador.

Si un grupo de desarrolladores trabaja en los mismos proyectos durante meses, sin objetivos claros ni un final a la vista, es posible que se sientan frustrados y que su productividad disminuya.

El desarrollo de software es un esfuerzo intelectual, por lo que la motivación es el principal combustible para la productividad. Trabajar todos los días sin percibir que tu trabajo está generando resultados reales puede ser muy desmotivador.

Como se indica en algunas metodologías ágiles, la hoja de ruta de desarrollo debe dividirse en varios objetivos e hitos, que el equipo podría lograr en plazos cortos y que les darán una sensación de progreso y logro.

Capítulo II, párrafo 18

En la guerra, pues, deja que tu gran objetivo sea la victoria, no largas campañas.

Esta frase se puede interpretar de dos maneras:

Primero, puede verse como un precursor de la filosofía UNIX: escribir programas que hagan una cosa y la hagan bien . Al desarrollar software, siempre debe tener en cuenta el objetivo principal del programa, la característica clave que proporciona o el mayor problema que resuelve, y garantizar una implementación adecuada.

A veces puede inspirarse y pensar en una función realmente genial para agregar, pero no olvide que las aplicaciones que tienen muchas funciones que se usan con poca frecuencia tienen un nombre despectivo: bloatware .

En segundo lugar, la declaración también puede considerarse como un precursor de uno de los principios de desarrollo de software esbelto: entregar lo más rápido posible .

Cuanto antes entregue el software sin defectos importantes, antes recibirá comentarios del cliente y podrá incorporar los cambios en la próxima iteración.

Si, por otro lado, entrega software que no funciona, se perderá comentarios valiosos, porque los clientes no tendrán la oportunidad de probarlo correctamente. Esto hará que la próxima etapa de desarrollo sea más difícil o imposible en situaciones en las que su próxima iteración dependa de los comentarios de los clientes.

Sin liderazgo, sin resultados

Capítulo III, párrafo 11

Ahora bien, el general es el baluarte del Estado; si el baluarte está completo en todos sus puntos, el Estado será fuerte; si el baluarte es defectuoso, el Estado será débil.

Esta cita describe la importancia del rol del gerente en un equipo de desarrollo: el éxito de un proyecto depende de la fuerza de todas las personas involucradas, y el gerente es el baluarte del proyecto. La responsabilidad comienza en la parte superior.

Aunque los desarrolladores con frecuencia trabajan solos (cada uno sentado detrás de una computadora, con comunicación limitada con sus compañeros de trabajo), eso no significa que no necesiten un buen liderazgo. Los gerentes de proyecto están a cargo de mantener al equipo encaminado, asegurando una comunicación efectiva y resolución de disputas, y los líderes, obviamente, definen las prioridades del proyecto (entre otras tareas), por lo que no se debe subestimar su rol. Tampoco su responsabilidad si algo sale mal. ¿Imagínese lo que le sucedería a un líder militar cuya unidad no cumplió con su deber en el campo de batalla?

Un equipo puede producir un gran software incluso si tiene algunas manzanas podridas en puestos de desarrollo, pero es poco probable que eso suceda si el gerente del proyecto es la manzana podrida , sin importar cuántos desarrolladores estrella tenga el equipo.

Capítulo VI, párrafo 28

No repitas las tácticas que te han dado una victoria, sino deja que tus métodos sean regulados por la infinita variedad de circunstancias.

A veces, al iniciar un proyecto, es tentador usar el mismo conjunto de tecnologías que usamos en proyectos exitosos anteriores (el mismo lenguaje de programación, las mismas bibliotecas, el mismo servidor, etc.). Sin embargo, a menos que los requisitos de los nuevos proyectos sean exactamente los mismos que los anteriores, este podría ser un enfoque incorrecto.

En programación, como en la mayoría de los dominios, la panacea (un supuesto remedio capaz de curar todas las enfermedades) no existe. No existe una única combinación de tecnologías que pueda utilizar para resolver todos los problemas; Cada tecnología tiene sus pros y sus contras.

Por supuesto, aprender un nuevo lenguaje de programación o usar una API desconocida puede ser costoso inicialmente, pero a largo plazo, la calidad del software será superior y te convertirás en un mejor desarrollador.

Capítulo XIII, párrafo 27

Por lo tanto, solo el gobernante ilustrado y el general sabio utilizarán la más alta inteligencia del ejército con fines de espionaje, y por lo tanto lograrán grandes resultados. Los espías son un elemento muy importante en la guerra, porque de ellos depende la capacidad de movimiento de un ejército.

Esta frase puede interpretarse como la importancia de utilizar herramientas de monitoreo y bibliotecas de registro durante la fase de mantenimiento.

Aunque a veces los clientes no lo crean así, el desarrollo no termina cuando obtiene una versión estable y completamente probada. El software siempre está evolucionando, ya sea corrigiendo errores, agregando nuevas funciones o mejorando la eficiencia.

Y no hay mejor fuente de información para saber qué cambios hacer que disponer de espías monitoreando el software en entornos de producción, comprobando qué funcionalidades se utilizan más, los errores más comunes y las operaciones más largas.

Los informes de errores, las entradas de registro y los datos de uso son fundamentales para detectar errores, identificar cuellos de botella y otros problemas, ya que no siempre es posible reproducir las mismas condiciones en entornos de prueba controlados.

trabajo en equipo y motivación

Capítulo X, párrafo 24

Aquel que avanza sin buscar la fama, Aquel que retrocede sin escapar de la culpa, Aquel cuyo único objetivo es proteger a su pueblo y servir a su señor, El hombre es una joya del Reino.

Básicamente, esta es la antigua versión china de "no hay yo en el equipo" . Es más importante trabajar junto con otros que buscar el beneficio personal.

El desarrollo de software es una actividad compleja que requiere que los desarrolladores trabajen en equipo de manera efectiva. Un buen desarrollador no es el que corrige la mayoría de los errores, implementa la mayoría de las funciones o finaliza las tareas antes de lo previsto; un buen desarrollador es aquel que ayuda al equipo a alcanzar sus objetivos.

Reclamar crédito por todo lo que ha hecho, no reconocer sus errores o culpar a otros por ellos, o llamarse a sí mismo un ninja del código podría engañar a algunos gerentes sin experiencia e incluso podría obtener un aumento, pero se convertirá en un miembro contraproducente de su equipo.

Capítulo VII, párrafo 21

Reflexiona y delibera antes de hacer un movimiento.

Esta frase indica la importancia de las reuniones de desarrollo de equipos, como las que proponen las metodologías ágiles.

Cuando se trabaja en equipo, es importante analizar cualquier cambio importante antes de implementarlo. No importa si eres el líder del equipo, o si eres la persona con más experiencia en el tema, siempre debes hablar, o al menos informar, al resto del equipo.

Recuerde que otros desarrolladores podrían brindarle información sobre partes desconocidas del software. Esto significa que podrían comenzar a implementar los cambios más rápido de lo esperado, porque podrían ser plenamente conscientes de los efectos de dichos cambios.

Capítulo X, párrafo 25

Considera a tus soldados como a tus hijos, y te seguirán hasta los valles más profundos; míralos como a tus propios hijos amados, y estarán a tu lado hasta la muerte.

Esta cita indica la importancia de la motivación, un principio de gestión que a veces es olvidado por los gerentes y líderes de equipo. Los desarrolladores motivados escribirán mejor código, trabajarán más rápido, cometerán menos errores y estarán más dispuestos a dedicar horas extra.

La motivación debe ser generada por los gerentes, interesándose genuinamente en sus subordinados, escuchándolos, preocupándose por el equilibrio entre el trabajo y la vida personal, construyendo entornos de trabajo positivos y preocupándose por sus trayectorias profesionales.

Además, no debes confundir motivación con remuneración. Estudios recientes demuestran que el dinero no motiva a la mayoría de los trabajadores, el dinero es principalmente bueno para atraer y retener empleados, pero no para hacerlos felices con sus trabajos. Por lo tanto, los aumentos de sueldo y las promociones no deben verse como herramientas de motivación.

Pensar más allá

Capítulo V, párrafos 7, 8 y 9

No hay más de cinco notas musicales, pero las combinaciones de estas cinco dan lugar a más melodías de las que jamás se pueden escuchar.

No hay más de cinco colores primarios, pero combinados producen más matices de los que jamás se hayan visto.

No hay más de cinco sabores cardinales, pero las combinaciones de ellos producen más sabores de los que se pueden probar.

Una de las cosas buenas de la programación es que las posibilidades son infinitas; puedes desarrollar básicamente donde quieras (al menos, mientras no sea un problema NP-completo).

Aplicaciones móviles, webs, juegos, aplicaciones de escritorio… si sabes programar, todas están a tu alcance.

Capítulo III, párrafo 1

En el arte práctico de la guerra, lo mejor de todo es tomar el país del enemigo entero e intacto; destrozarlo y destruirlo no es tan bueno. Así también, es mejor capturar un ejército entero que destruirlo, capturar un regimiento, un destacamento o una compañía entera que destruirlos.

Cuando se trabaja en un proyecto con una gran base de código, es común encontrar módulos o secciones de código que se han implementado con malas prácticas o utilizando bibliotecas obsoletas. Aunque puede ser tentador borrar (o destruir) este código, puede que no sea la mejor idea por varias razones:

• El código heredado no es necesariamente malo, a veces es un buen código que se escribió cuando se consideraba que otras metodologías y tecnologías eran el camino a seguir. Sin embargo, el hecho de que sea antiguo no significa que no funcione.

• Es posible que pierda tiempo corrigiendo el código que aún funciona en lugar de concentrarse en corregir otras partes más críticas del código.

• A menos que esté realmente seguro de lo que está haciendo, reemplazar una sección de código que funciona significa que corre el riesgo de introducir nuevos errores o fallas.

Esto no significa que la frase “Si no está roto, no lo arregles” sea una buena estrategia, sino que todo proyecto tiene prioridades, objetivos y limitaciones de tiempo. Entonces, si encuentra un código que podría mejorarse, discútalo con el resto del equipo o con el gerente del proyecto para determinar cuándo optimizarlo.

Capítulo VIII, párrafo 3

Hay caminos que no se deben seguir, ejércitos que no se deben atacar, pueblos que no se deben asediar, posiciones que no se deben disputar, órdenes del soberano que no se deben obedecer.

Aunque no lo diga directamente, podríamos interpretar este principio como una advertencia para evitar antipatrones.

Aunque el uso de un antipatrón puede resolver un problema a corto plazo, debe recordar que a largo plazo será contraproducente. Por lo tanto, no importa cuánto tiempo ahorre, cuántos errores corrija o qué tan conveniente sea para usted, evítelos.

Aún así, hay ocasiones en las que puede sentirse tentado a usar un antipatrón para resolver una tarea urgente, prometiéndose que implementará una solución adecuada cuando tenga más tiempo, pero recuerde una de las leyes de Murphy: todas las soluciones rápidas se convierten en cambios permanentes.

Conclusión

Aunque desarrollar software es diferente a comandar soldados en la guerra o liderar un país, todos ellos deben resolver problemas que requieren trabajo en equipo, buen liderazgo, eficiencia y soluciones a largo plazo.

Sin embargo, El arte de la guerra no es el único libro que contiene principios que pueden aplicarse al desarrollo de software. El Príncipe de Nicolás Maquiavelo, es un ejemplo.

De hecho, aquí hay una lista de citas de Maquiavelo que aún son relevantes. Intenta adivinar cuáles son los principios correspondientes en el mundo del desarrollo de software.

1. El león no puede protegerse de las trampas y el zorro no puede defenderse de los lobos. Por lo tanto, hay que ser un zorro para reconocer las trampas y un león para asustar a los lobos.
2. Nunca intentes ganar por la fuerza lo que se puede ganar con el engaño.
3. Nunca se logró nada grande sin peligro.
4. Quien desee el éxito constante debe cambiar su conducta con los tiempos.
5. Los hombres en general juzgan más por las apariencias que por la realidad. Todos los hombres tienen ojos, pero pocos tienen el don de la penetración.
6. El que quiere ser obedecido debe saber mandar.
7. La sabiduría consiste en saber distinguir la naturaleza de los problemas y en elegir el mal menor.
8. No se puede evitar la guerra; solo puede posponerse en beneficio de su enemigo.
9. La naturaleza crea pocos hombres valientes; la industria y la formación hace muchos.