Eficacia vs. eficiencia del programador.

El mataburros define programador como "Persona que elabora programas de ordenador." (segunda acepción, que es la que viene al caso). Si buscamos programa nos encontramos (entre otras, 12ava acepción) con "Conjunto unitario de instrucciones que permite a un ordenador realizar funciones diversas, como el tratamiento de textos, el diseño de gráficos, la resolución de problemas matemáticos, el manejo de bancos de datos, etc.".

Así que llegamos a la asombrosa conclusión de que un programador es una persona que elabora un conjunto unitario de instrucciones que permite a un ordenador realizar funciones diversas... etc.

Me voy a tomar la libertad de agregar una condición, que no por obvia es menos importante: "...que permite a un ordenador realizar funciones diversas en razonable concordancia con sus deseos..." Es decir, el ordenador tiene que realizar las funciones que el programador quiere y no otras, y esta igualdad debe ser "razonable" porque ya sabemos que todo software tiene errores.

Entramos en terreno escabroso, ya que "razonable" es un adjetivo muy subjetivo. Así que, en un acto de descarado libertinaje, modifico y agrego un tercer elemento: "...en razonable concordancia con los deseos de quien utiliza o requiere tal función...". Ha nacido el usuario o el cliente.

Bien. Llego entonces a la conclusión de que un programador es quien puede hacer que un ordenador haga razonablemente lo que el usuario o cliente desea, según la subjetiva evaluación de este último. Tengo que recordar en este punto que ya no se trata de una definición de diccionario sino de mi personalísima y discutible opinión, ya que la he modificado bastante. Pero es justamente esto lo que quiero expresar.

Decir que un programador es "eficaz" es una tautología (segunda acepción: "Repetición inútil y viciosa.", como estos links que ya me cansé de poner). Si no soy eficaz no soy programador.

Una empresa que desarrolla software contrata personal que se dice programador. Con el paso del tiempo esto queda demostrado: hace su trabajo entregando software que funciona razonablemente (es eficaz) o lo echan con justa causa, ya que la persona ha engañado a su contratista diciendo poder hacer lo que no puede.

Ahora, ¿qué parámetros se tienen en cuenta en la evaluación que toda empresa o equipo de trabajo hace de sus integrantes y que implica premios, ascensos, vacaciones o al menos renombre entre sus pares y respeto por parte de sus superiores? A veces, sólo la eficacia. Por ejemplo: se entrega un premio por proyecto completado (a secas, no "completado en tiempo" ni "completado y certificado por la norma xyz"). Es decir, se premia a una persona simplemente por hacer su trabajo, por hacer lo mínimo indispensable que define su puesto. Pero se supone que un premio o el renombre y el respeto van de la mano de una habilidad que está por encima de la línea base. Es como si en una facultad me dieran un premio o gozara de renombre académico por aprobar con 4 (el mínimo requerido). ¿Me recibo con un 4 en todas las materias? Sí. ¿Soy tan "Licenciado en Sistemas" como cualquier otro? Sí. Pero no es menos cierto que soy el "peor Licenciado en Sistemas" posible, ya que si tuviese menos de 4 no sería ni Licenciado (es sólo una analogía para graficar la cuestión, ya sé que luego en la vida profesional es donde se demuestran las verdaderas aptitudes, etc.).

Esto sucede porque a veces se comete el error de medir la calidad de un software solamente desde el punto de vista del cliente, interno o externo. Y esta falencia tiene que ver con el hecho de que incluso para un Líder de Proyecto es difícil obtener otras medidas sobre la calidad del producto de un programador y de su desempeño.

En resumen: un programador se define por su eficacia. Pero su desempeño debe medirse por su eficiencia. ¿Qué es la eficiencia, dentro del marco de este artículo? Lo uso como sinónimo de la suma de legibilidad, mantenibilidad, corrección, simpleza, ese tipo de cosas.

Es tan dificil para un no-programador (cliente, analista funcional, líder de proyecto) medir la eficiencia de una porción de código o de un sistema como fácil lo es para sus compañeros de equipo. Todos nos damos cuenta cuando "esta parte no te quedó muy bien", o cuando "ese sistema está podrido por dentro".

Hay otra cuestión sutil, que es muy interesante: el miembro más inexperto del equipo es el que tiene, a mi entender, la opinión más relevante. Si éste programador -que puede ser un junior en su primer desarrollo- entiende el código (obviamente con la tutela necesaria), le resulta claro y fácil de modificar o depurar, y muestra un claro progreso y adaptación espontáneos a medida que adquiere experiencia, es motivo de orgullo para el que lo escribió así sea el más experimentado programador del mundo. Mucho más que la opinión de otros compañeros más expertos, quienes a veces ni ven las ambigüedades por conocer bien el sistema, y ni que hablar del cliente, que sólo puede ver que hemos hecho nuestro trabajo, que es lo mínimo que él espera, o del Líder de Proyecto que a veces -remarco "a veces"- sólo evalúa los proyectos mediante "horas ejecutadas vs. horas presupuestadas".

¿Nunca se han sentido frustrados por la reacción de un cliente ante un software del cual el equipo está justificadamente orgulloso? Yo los consolaría diciendo (y me consolaría, porque también me pasa) "¿qué esperábamos?". El fruto de nuestro especial esfuerzo, de nuestro apego a rajatabla por los estándares y el buen diseño ha sido oculto por esa empaquetadora llamada compilador antes de llegar a sus manos.

El esfuerzo tiene su recompensa. El código es mantenible, los errores, muchos o pocos, se corrigen sin grandes problemas, el sistema es escalable y la nueva funcionalidad resulta más sencilla de desarrollar ya que tiene una base estable. Pero... muchas veces se premia más a quien se esfuerza por corregir errores y trabaja a deshoras que al que ha desarrollado código mantenible, y por ello logra resolver cada cuestión en un par de minutos, retirándose temprano. Incluso vemos que el que se fue temprano no ha tenido oportunidad de demostrar su "compromiso", y con suerte nunca se presente.

No soy un experto en medidas de la calidad interna del software, así que no puedo presentar el formulario de evaluación mágico que resuelve el problema del Líder de Proyecto, que a esta altura debe estar pensando "bueno, sé que esta situación existe ¿pero cómo evalúo en concreto el desempeño de cada uno?". Me quedo con esta pregunta, y con el plan de googlear un poco en busca de respuestas, que seguro que las hay.

Resumo, para finalizar, los conceptos centrales de todo este artículo:

• Todos hacen, no todos hacen bien, y nadie hace bien siempre.
• Todos los programadores somos eficaces. Es la eficacia (o al menos su apariencia, real o no) ante los superiores, clientes y compañeros lo que nos mantiene dentro del equipo. Nuestro esfuerzo debe concentrarse en ser cada vez más eficientes. Para esto no hay límites.
• Necesitamos de la buena opinión de nuestros clientes (internos o externos) para sobrevivir. Condición necesaria, pero no suficiente.
• Es la opinión de nuestros compañeros de equipo que conocen a fondo nuestro trabajo la que más debemos tener en cuenta para determinar si somos buenos en lo que hacemos o no, y es a ellos a quienes tenemos que acudir o prestar atención para ver qué es lo que se puede mejorar (si es que queremos hacerlo).