¡Fin de semana!

Visto en The Daily What.

Programar es como…

… “escribir”, decía yo (y varios pensaban lo mismo). @programmingjoy rescató del blog de Ian Voyce una entrada en la que se recopilan otras analogías, como el clásico “programar es como tener sexo…

• … un error y tendrás que mantenerlo el resto de tu vida”.
• … podés divertirte un montón y que alguien más se haga cargo del lío (para aquellos que cambian de trabajo con frecuencia).
• … tenés que pagar un montón para conseguir a alguien bueno en eso” (por favor no arruinemos un buen chiste discutiendo sobre la veracidad de esta analogía en particular).

Pero mejor sigan hacia la entrada original para encontrarse con el resto: Programming is like a bad analogy.

Complejo.

Hace semanas que vengo demorando una entrada sobre la complejidad. Es que hay tanto que decir sobre la complejidad que la cosa se vuelve un poco compleja… y soy poco dado a las cosas complejas.

Así que procrastinando otra vez el bendito post –que a estas alturas ya sé que nunca voy a escribir-, picando de aquí y allá en el reader, me encuentro con un -ya viejo- artículo de Joel: The Duct Tape Programmer.

Sencillamente imperdible, un compendio de frases impactantes delicadamente hilvanadas:

Sometimes, you’re on a team, and you’re busy banging out the code, and somebody comes up to your desk, coffee mug in hand, and starts rattling on about how if you use multi-threaded COM apartments […] and you have no friggin’ idea what this frigtard is talking about, but he just won’t go away, and even if he does go away, he’s just going back into his office to write more of his clever classes […]

Ya ven para donde apunta:

One principle duct tape programmers understand well is that any kind of coding technique that’s even slightly complicated is going to doom your project.

Y básicamente eso es todo lo que hay que decir al respecto de la complejidad. Me hizo acordar a esta otra gran frase, que no recuerdo muy bien de dónde saqué:

“Los buenos programadores resuelven los problemas complejos, los grandes programadores los evitan”.

Resolver un problema es ganar una batalla. Eliminar la necesidad de resolverlo es evitar la guerra. Es como la depuración: no se trata de meter más código sino de quitar el que sobra, no se trata de conocer más patrones, frameworks, herramientas, plugins y la mar en coche, se trata de encontrar la combinación más simple que nos permita implementar la funcionalidad necesaria, y de simplificarla todavía más.

Para evitar un problema es imprescindible crear el ambiente propicio para esas preguntas que ponen incómodos a todos: “¿realmente hace falta hacer esto? ¿por qué? ¿para qué? ¿hay otras posibilidades? ¿qué pasa si no hacemos nada?” Son esas preguntas las que llevan al pensamiento lateral, y es por eso que la aparición de respuestas tautológicas nos alertan tempranamente de que estamos perdiendo el rumbo: “Porque sí”, “Porque el cliente lo pidió así” (es casi decir lo mismo), “No sé, pero hay que hacerlo”, “Esto ya está pensado”…

Lo complejo se torna complicado muy rápidamente, casualmente en el preciso momento en el que los ingeniosos desaparecen.

Jueguitos de Lunes.

Una buena opción al trabajo ésta que publicó Cerebrado en Soft Cero: Breakdown es una versión del clásico Arkanoid convenientemente camuflada para jugar en la oficina.

 

Digo yo… ¿no será hora de buscar un trabajo más motivador?

Decisiones sobre calidad.

Del dicho al hecho hay un largo trecho, qué duda cabe. Y cuando se habla de calidad (sobre todo cuando se habla) el trecho es más bien un largo recorrido.

Si hacen el experimento de pasear un poco por sus ambientes de desarrollo preguntando “¿Cómo se implementa un software de calidad?” recabarán respuestas ubicables en un amplio rango que va desde la opinión improvisada (la mía, por ejemplo) hasta la disertación fundada. Increíblemente, la mayoría de las respuestas serán muy razonables (¡hagan la prueba!). Podríamos decir que casi todo el mundo sabe cómo contribuir a la buena calidad de un producto de software.

Qué duda cabe. ¿Y entonces? ¿Qué pasa? Vamos, ustedes saben a qué me refiero (y si no saben tienen un problema más grave todavía). Creo que una –entre tantas otras- cosas que pasan es que un nivel de calidad por sobre la media (abreviemos en “la calidad” de aquí en más) conlleva un costo que muy pocas empresas están dispuestas a asumir.

Un error de concepto muy extendido que ninguna consultora en calidad con sentido comercial corrige es la confusión entre el costo de la calidad y el precio de la implementación o certificación de normas de calidad.

La confusión entre aquel costo y ese precio conviene a ambas partes: en la empresa alguien vende -y alguien compra- que erogando una suma inicial de $xxx y un mensual de $zzz asegura la calidad de su producto o proceso de desarrollo, y la consultora disimula el hecho de que por esos importes sólo se hace cargo de la inducción y formación del personal en determinadas normas y procedimientos, y que el impacto de esta formación sobre la calidad final de los resultados es un tema que estará por verse (y que la relación entre estos dos elementos –formación y resultados- es, por decir lo menos, controversial).

Como escribí más arriba, es mi opinión que pocas empresas están dispuestas a pagar el verdadero costo de la calidad. Pero… si no es el precio que cobra la consultora por certificar la norma “Pepito 9000”… ¿qué es?

Calidad es funcionalidad que hay que programar o documentos que hay que escribir, porque finalmente todo lo que realmente existe tuvo que programarse o escribirse en algún momento, magia no hay (aunque sí mucho humo). Funcionalidad es tiempo, tiempo es dinero. Dinero –poco- con el que se paga a los programadores o –mucho- con el que se compran herramientas (y que termina –en ínfimas proporciones, se deduce de lo anterior- en los bolsillos de otros programadores).

Así que la calidad en la práctica diaria del desarrollo de software, una vez despojada de esa pesada carga ornamental de normas y procedimientos, es simplemente un subconjunto de las decisiones mediante las que día a día, minuto a minuto, intercambiamos funcionalidad por tiempo –que en algún momento futuro se cambia por dinero-. Lo que lo define a este subconjunto de decisiones es que se refieren a funcionalidad que -por una u otra razón- podemos gambetear (esquivar)… en realidad no gambetear del todo, sino patear para más adelante por un tiempo determinado, aunque usualmente se pretenda hacerlo indefinidamente.

¿Cómo que funcionalidad que podemos patear para adelante? Me explico. Otra –a mi entender- confusión conveniente –esta vez a empresas de desarrollo de software- es aquella entre cumplimiento y calidad. Se suele decir que un producto de calidad es aquel cumple con los requerimientos que ha solicitado el cliente, y que por lo tanto la contribución del equipo de desarrollo a la calidad es asegurarse de cumplir con esos requerimientos. Bueno, eso no es así.

En tanto la especificación de un producto de software dista mucho de tener la precisión de los planos para una silla, una mesa o un auto, esa definición disfraza el cumplimiento –entregar lo que según un papel se nos pide- de calidad –entregar un producto acorde a las expectativas del cliente (usualmente esto es, todos lo sabemos, algo muy diferente a lo que el cliente pide)-.

Entre la reducida audiencia de este blog nadie se escandalizará demasiado si digo que tranquilamente podemos cumplir con todos los requisitos con un sistema de mier… ejem, y que también podemos entregar un software de excelentísima e irrefutable calidad que no cumpla, ya sea por error u omisión, con alguna o todas las expectativas (ojo, no los requisitos sino las expectativas)… o que a veces se manipulan las expectativas del cliente de manera tal que coincidan con lo que se desea entregar (y que en muchas de esas veces ese tiro sale por la culata).

La calidad está (como Dios, dicen) en los detalles (mi ateísmo es clara indicación de la calidad de mi trabajo).

La calidad aparece cuando no gambeteamos aquellas funcionalidades que sí podríamos gambetear, cuando no pateamos desesperadamente para adelante (o para afuera), cuando entregamos al cliente no lo que pide sino lo que necesita… y todo ello lleva tiempo e implica riesgos.

¿Cuánto? Dependerá, pero seguro más que no hacerlo.

En resumen, y para decirlo de una vez por todas: el costo de la calidad es el tiempo extra que nos tomamos al entregar más tarde algo bien hecho en vez de entregar a tiempo algo para cumplir…

…y, por sobre todas las cosas, el costo de los fracasos derivados de los riesgos asumidos (todos dicen arriesgar pero nadie piensa en fracasar, y no hay riesgo sin fracaso): nada ni nadie nos asegura hoy que dentro de n días tendremos un producto de calidad, o que nosotros sí sabremos lo que el cliente necesita y no puede expresar, o que lograremos esquivar las balas sin escondernos cobardemente en esa armadura de papel a la que llamamos “requerimientos escritos”.

¿Conocen a alguien realmente dispuesto a ello?