¿Debería adoptar una metodología o centrarse en la resolución de problemas? ¿Están estos enfoques en desacuerdo o pueden haber puntos en común?
La historia del debate humano sobre el valor de la tradición frente al progreso es tan antigua como la propia civilización occidental. Todos los campos del quehacer humano, desde la filosofía hasta la ciencia, han sido testigos del choque entre puristas y pragmáticos que luchan por decidir qué enfoque es más confiable.
Irónicamente, ni siquiera el mundo empresarial, un entorno social conocido por su visión del mundo muy pragmática, es inmune a este debate. Los desarrolladores de software, administradores y científicos de datos han experimentado, en un momento u otro, tensión entre quienes promueven una metodología o estilo y quienes tienden a preferir un enfoque ecléctico.
Entendiendo el debate
He decidido utilizar los términos purista y pragmático para referirme a cada lado de este debate. Estos conceptos no tienen ninguna inclinación filosófica, decidí usarlos porque se explican por sí solos.
Por puristas nos referimos a tradicionalistas, o personas que tienen una visión del mundo bien definida y cuyos valores y comportamientos reflejan ese mundo lo más fielmente posible. Imagine un desarrollador de software que es un firme partidario de una metodología ágil o en cascada, que no está dispuesto a comprometer sus principios.
Los pragmáticos, por otro lado, son personas que tienen una visión del mundo flexible. Están menos interesados en seguir un método y más centrados en el resultado. Si tuviéramos que describir sus creencias fundamentales en una frase, sería "lo que funcione".
Pero la realidad rara vez es tan clara y fácil de definir; en lugar de pensar en esta división como las dos caras de una moneda, es más probable pensar en ella en términos de un continuo. La mayoría de nosotros no somos puristas radicales ni pragmáticos, tenemos un poco de ambos.
A algunos de nosotros nos gusta la estructura de las metodologías, mientras que a otros les gusta la libertad y la creatividad de un enfoque más libre. Cualquiera sea el caso, la mayoría de nosotros estamos más que dispuestos a llegar a un acuerdo en el contexto adecuado. Desgraciadamente, no siempre es así y es aquí donde a veces podemos encontrarnos ante un callejón sin salida.
Cuando los métodos importan
Cuando un amigo mío enseña en su taller, siempre cuenta una historia muy divertida. Cuando empezó como desarrollador de software, el primer trabajo que consiguió fue en una empresa que anunciaba con orgullo que era una empresa de desarrollo 100% orientada a objetos.
En el primer proyecto de mi amigo, el equipo quedó perplejo porque tenían un problema que no era fácil de modelar con un enfoque orientado a objetos. Mi amigo pensó en algunas soluciones, ambas requerían un poco de programación imperativa, pero sus ideas fueron descartadas porque no era el estilo de la empresa.
Por divertido que parezca, esta es una historia real y te sorprendería lo común que es. Ni siquiera tiene que ser un paradigma de programación. Los defensores de la cascada o la metodología ágil pueden ser tan rígidos en sus posiciones como lo fue esta empresa con su enfoque del desarrollo de software.
Hay multitud de razones por las que esto sucede. Una explicación es la falacia del costo hundido: algunas empresas han invertido tanto tiempo y esfuerzo en dominar un enfoque particular que terminan aplicándolo a todo, incluso si el enfoque no fue diseñado originalmente con esa intención.
Tiendo a optar por una explicación menos cínica. Los seres humanos son criaturas de tradiciones y hábitos, las sociedades se basan en rituales. Y por sociedad me refiero a todo, desde las civilizaciones hasta las unidades familiares, incluidas las empresas.
La identidad de una empresa se define en parte por sus prácticas y tradiciones. Los marcos y las metodologías proporcionan un lenguaje común que se comparte entre todos los miembros; considérelos como atajos semánticos. Formas en que podemos compartir información rápidamente con personas que comparten nuestro marco de referencia.
Cuando actuamos fuera de esta cosmovisión, la comunicación se vuelve más difícil, es más difícil transmitir la idea y corremos el riesgo de romper estándares o desconectarnos por completo de la comunidad.
Por ejemplo, imaginemos una empresa que busca seis sigma, con la excepción de un departamento cuyo gerente se adhiere obstinadamente a otras formas de mejora de procesos.
Si usted, como consultor, comprobara la productividad de cada departamento, tendría más dificultades con este departamento, ya que su enfoque es diferente de los demás, es más difícil evaluar su desempeño en comparación con los demás.
Volviendo a mi amigo, puede que tenga razón, pero ¿qué pasaría si implementaran la solución y unos años más tarde otro equipo heredara el proyecto, sólo para encontrar este extraño fragmento de código imperativo en un software orientado a objetos? Para ellos, puede resultar más difícil entender cómo debería funcionar el código.
La innovación es, por naturaleza, disruptiva, por lo que no es raro que encuentre resistencia, especialmente si esa innovación va en contra de los valores fundamentales o las normas sociales del grupo.
El desarrollador pragmático
Ahora imaginemos todo lo contrario: un desarrollador de software que construye su proyecto basándose en puro pragmatismo: si funciona, funciona. Sería el primero en admitir que para la mayoría de nosotros sería fantástico poder escribir código como quisiéramos.
Desafortunadamente, esto simplemente no es factible. Cuando escribimos código, especialmente para otros, debemos comprender que es posible que no existamos para siempre. Como tal, nuestro trabajo no puede ser idiosincrásico; debe ser capaz de comunicar intenciones, necesita una estructura que otros puedan seguir.
Por supuesto, una vez más, este es un ejemplo extremo. Los pragmáticos no son maestros del caos, simplemente creen que encontrar una solución a un problema es más importante que respetar un conjunto de normas o tradiciones definidas que pueden resultar restrictivas.
Quizás el mejor ejemplo de desarrolladores pragmáticos sean aquellos que practican metodologías híbridas, mezclando la estructura del enfoque en cascada con la entrega rápida y la participación del usuario de las tradiciones ágiles.
Un rasgo común entre los pragmáticos tiende a ser su nivel de experiencia. Los desarrolladores senior son más propensos a la experimentación y menos dependientes de los enfoques tradicionales.
Vea, por ejemplo, cómo la inmensa mayoría de las personas que trabajan con Clojure (un lenguaje de programación funcional basado en Java) son desarrolladores senior que están cansados de trabajar con programación orientada a objetos.
Esto no es raro. Como postula Khun en su libro sobre las revoluciones científicas, cada paradigma tiene un límite, un punto en el que se desintegra. Es entonces cuando el especialista se da cuenta de que necesita un nuevo paradigma para solucionar su problema.
Si la estructura proporciona un marco común, entonces la innovación es lo que lleva ese marco a sus límites. La alternativa es bastante deprimente: el tradicionalismo promueve el estancamiento. Si nos mantenemos fieles a nuestros métodos seguros y confiables, llegaremos a un punto en el que simplemente no podremos adaptarnos.
Y eso es lo último que queremos en un negocio que se acelera minuto a minuto.
Los opuestos se complementan
El psicoanalista Carl Gustav Jung entendió perfectamente que las fuerzas opuestas no son contraproducentes, sino que, cuando encuentran el equilibrio adecuado, se potencian mutuamente.
El pragmatismo y el purismo no son opuestos, en el sentido de que un enfoque no excluye ni invalida al otro. Seguir sus métodos crea estructura, probar nuevas soluciones supera sus límites.
Comprender el valor de cada enfoque y promover una cultura que valore ambos es, en mi opinión personal, la mejor manera posible de promover una empresa flexible con un núcleo fuerte que se adapta pero mantiene su esencia.
