Estándares vs. creatividad en la codificación

Una charla de oficina un tanto extraña: ¿una metodología de desarrollo muy establecida va contra la creatividad de los programadores, llevándolos hacia un trabajo rutinario y finalmente hacia la desmotivación?

Acotemos el tema al tipo de sistemas que desarrolla el equipo en donde se da esta discusión: un sistema informático que soporta un circuito administrativo, una base de datos que es actualizada con los movimientos diarios propios del negocio a través de una interfaz relativamente simple. Buena parte de la aplicación (no me atrevo a tirar porcentajes, pero deben ser elevados) consiste en ABMs (pantallas de Alta-Baja-Modificación de datos, por las dudas) o reportes (desplegados con la herramienta xxx que accede directamente a la base).

Por supuesto, eso es la **mayor parte** de la aplicación. Hay otras funcionalidades que pueden dar dolor de cabeza al más avezado o quedar muy bien en su portafolio de logros.

En este contexto, puede surgir una forma muy establecida de hacer ciertas cosas. Por ejemplo: existe una herramienta que genera los ABMs todos igualitos con relativo poco esfuerzo, hay un entorno para los reportes de manera que la pantalla de ingreso de parámetros se arma también con relativa facilidad, etc.

Pero claro, luego de una curva de aprendizaje más o menos rápida hacer un ABM o un reporte ya no representa un desafío, y puede llegar a ser bastante monótono.

Creo que mi forma de presentar la cosa ya resume mi posición: en todo caso lo desmotivante y monótono es un negocio en particular, que puede ser estático o con funcionalidades muy establecidas, y puede estar en la pericia del que coordina distribuir las cosas de manera tal que a cada uno le toque "parte aburrida y parte divertida".

Si bien puede resultar divertido buscar nuevas maneras de hacer lo mismo, no deja de ser una pérdida de tiempo si no está justificado por una necesidad del negocio o una oportunidad para él.

Se ha dicho también que cuando el framework del equipo resuelve muchos problemas en los niveles más bajos (desde la conexión a la base hasta la seguridad, por ejemplo) los programadores no "aprenden" ya que se les "oculta" funcionalidad, y surge la desmotivación por no tener poder de decisión sobre el framework, como si éste fuera el castillo de unos pocos al que todos quieren entrar.

Enfocándonos en el tema de la idealización del framework y de la arquitectura del mismo (ya que ¡hola! las aplicaciones **también** necesitan una arquitectura enfocada al negocio, independientemente de la del framework), como algo divertido, siempre cambiante y a la cabeza de la tecnología, voy a tirarle un par de ladrillos a ese castillo de cristal.

Creo que últimamente se ha establecido la idea de que la carrera de un programador es: junior -> semi-senior -> senior -> arquitecto de software. No entiendo esto último, realmente (talvez tenga que ver con que "arquitecto" suena... importante, y "senior" suena solamente a viejo). Construir un framework es similar a construir determinado tipo de aplicaciones, no indica mayor o menor pericia del programador sino cierta especialización en un área determinada del desarrollo, y por lo tanto debería tener que ver ver con el tipo de orientación que el programador elige.

En mi opinión todos deben tener acceso -"de lectura"- a todo el código incluído el framework, pero así como se distribuyen tareas de codificación en la aplicación, también se distribuyen en el framework. Éste tiene la particularidad de que sufre realmente mucho cuando hay "demasiadas cabezas adentro", y propaga esa inconsistencia a todas las aplicaciones. Debe tener una y preferentemente sólo una filosofía subyacente y debe respetarse, ya que ofreciendo demasiadas maneras de hacer lo mismo las soluciones se complican en vez de facilitarse. Para decirlo crudamente, no deberían haber muchos monos en el baile.

Una solución para cada problema, que puede mejorarse o cambiarse, pero no duplicarse.

Por otro lado, el negocio es el negocio. El objetivo del equipo es desarrollar aplicaciones, no entornos de desarrollo. Cuando el framework alcanza el nivel de madurez necesario para construir las aplicaciones que el negocio necesita debe estabilizarse y los esfuerzos concentrarse en las aplicaciones ya que son el producto final del equipo y la fuente de ingresos para la empresa.

Un buen arquitecto jamás pierde de vista el negocio para el cual trabaja. En la mayoría de los casos esto implica saber cuándo parar: cuándo estabilizar el framework y concentrarse en el desarrollo de aplicaciones y cuándo es necesario volver sobre alguna parte de la arquitectura de apoyo para adoptar nuevas tecnologías o herramientas. Por otro lado esta posición en general asume tareas de coordinación hacia dentro y fuera del equipo que exceden las habilidades técnicas y hacen mucho al olfato y la experiencia en el manejo de equipos. ¡Cuidado aquellos que creen que el trabajo del arquitecto es una prueba continua de nuevos juguetes! Como en otras áreas, la mejor forma de aprender es acercándose de a poco, trabajando junto a alguien de experiencia, tomando al principio pequeñas decisiones, etc.

Un programador senior que en un cambio de trabajo se promociona como "arquitecto" suponiendo un paso más en su carrera puede llevarse una temprana decepción, o meterse en un bonito problema. Es como decirse experto en un negocio que no se conoce. Si yo digo que soy experto en sistemas de facturación estoy declarando mi experticia en un negocio, no mi nivel de programación. Nombrarse "arquitecto" indica un enfoque, conocer una tarea determinada en el desarrollo (que no es ni más ni menos que otras), no el nivel de manejo de una herramienta de programación.

Digamos, hay programadores que se orientan a negocios, comprenden rápidamente los circuitos administrativos, la mejor manera de resolverlos, la interacción con el usuario, etc. Otros se orientan a otro tipo de aplicaciones: científicas, de comunicaciones, servicios, con énfasis en la interfaz con el usuario, etc., y otros se orientan hacia la construcción de frameworks y librerías de apoyo, etc. Por supuesto la misma persona puede ser buena o ganar experiencia en varias áreas.

En este punto tengo que aclarar que personalmente me considero en una zona gris entre el negocio y la arquitectura. Es decir: me gusta trabajar en el framework, pero si no tuviese algo que hacer en el negocio me aburriría, y la coordinación me cansa terriblemente, si bien puedo hacerla. Obviamente dependiendo del caso hago uso del título marketinero, por qué no. Fin de la nota personal.

Todo esto para desmitificar un poco la idea Matrix-style del arquitecto que toca todos los hilos desde una superconsola de control.

En resumen, antídotos contra la desmotivación que se me ocurren al escribir esto:

• La principal: un equipo balanceado para cada proyecto. Si 10 programadores senior construyen una aplicación como la que describimos, las "tareas desafiantes" no alcanzan, y no hay vuelta que darle. En todo proyecto hay tareas para todos los niveles, por lo que deberían estar involucrados programadores de todos los niveles, de ser posible, claro.
• Siguiendo con la idea: buena distribución de tareas, tratando de olfatear la personalidad y la orientación de cada uno. Hay personas a las que no les gusta innovar, y personas a las que sí.
• Orientar la creatividad o las ganas de innovar en las funciones que realmente pueden hacer único al sistema, aquellas que pueden ayudar a venderlo, hacerlo más atractivo, más valioso. Si alguien tiene ganas de revolucionar una funcionalidad, que no sea un ABM.
• Y finalmente: nos guste o no, el buscar la motivación y el aprendizaje siempre depende en última instancia de uno mismo. La empresa puede tener más o menos intenciones de ayudar, pero lo hará o no en su propio beneficio. Léase por ejemplo: si el negocio es estable no podemos pretender revoluciones, y si queremos un cambio deberemos buscarlo en otro lado. El recambio en el equipo no es necesariamente malo ni para la persona ni para el conjunto, y no veo sentido en esa obsesión por retener a grandes programadores para los cuales ya no hay desafíos en el negocio. Un gran programador desmotivado es, ante todo, un programador desmotivado.