Diez Lastres Softwareros

Hablemos de diez cosas o creencias que, si desaparecieran de la faz de la Tierra mañana por arte de magia, no sólo no habría ningún inconveniente sino que nuestra vida como desarrolladores de software sería un poco más llevadera.

1. El arquitecto de software: Ya lo dije varias veces. Aquella figura mítica del tipo o tipa que se sienta a pensar arquitecturas abstractas 40 horas por semana y baja a sus discípulos sus diseños escritos en tablas de arcilla es una construcción mental que no me canso de comprobar que no funciona. Cada vez que veo algún conocido entronizado como arquitecto de software, sólo me queda desearle que el golpe contra el piso sea lo más gentil posible.

2. Modelos: o sea, si no tenés un diagrama de secuencia no sabés cómo arrancar? Elegí otra profesión, maestro (?). Dirán: el diagrama no es el modelo. ¿Qué es el “modelo” entonces? Nadie sabe. El modelo está en todos lados y en ninguna parte. Dicen que uno puede encontrar el modelo al final del arco iris. Muy probablemente, el modelo sea un mísero archivo perdido en /usr/local/.

3. El Scrum Master: Polémico. Sé que me estoy poniendo en contra al poderoso gremio de los scrum masters. Vengan de a uno. No se ofendan, pero los facilitadores surgen naturalmente; si tenés que forzarlo y darle un título, ya arrancamos mal. Además, no se facilita full-time. Se hace por momentos cuando surge la necesidad, y se hace inconscientemente. Luego, el facilitador natural vuelve a sus tareas y hace algo útil por el prójimo. Nadie puede facilitar full-time, y facilitar de forma consciente es artificial y se nota.

4. Calidad de mala calidad: Acá el lastre es la confusión desmedida que hay alrededor del concepto de calidad de software. Seguro, nadie quiere tener software que no anda o está lleno de bugs, pero es necesario que tengamos que hablar de esto usando infinidad de términos diferentes con niveles esotéricos de solapamiento?

   • Manejo de la calidad (quality management)

   • Aseguramiento de calidad (quality assurance)

   • Aseguramiento de producto (product assurance)

   • Calificación (qualification)

   • Aceptación (acceptance)

   • Control de calidad (quality control)

   • Verificación (verification)

   • Validación (validation)

   Cuánto más se busca información sobre esto, más profundo es el pozo donde nos metemos.
   Todos estos términos apuntan, palabras más, palabras menos, a ganar confianza en que los requerimientos que en algún momento se definieron se hayan materializado en el coso final. Ahora, si los requerimientos son cualquier banana, o fueron fabricados para salir del paso y cumplir con algún tema contractual, entonces no hay calidad posible, independientemente de cómo lo llames. Por eso, la mayoría de los esfuerzos—nobles, eso sí—por alcanzar la calidad son simplemente GIGO¹. Esto no puede volverse más meta: hay calidad de mala calidad.

5. El unit testing: cuántas veces hemos visto a un tipo/a escribiendo un “test” de unidad que no testea absolutamente nada significativo? ¿Cuántas horas ha invertido la humanidad en escribir tests técnicamente inútiles para contentar a algún revisor o similar? Y quién testea los tests? En general, se testea demasiado software siguiendo el método Volkswagen donde el escenario de test se altera para lograr un resultado deseado. La profecía autocumplida.
   El único test que vale es aquel hecho sin toquetear lo que se está probando, o toqueteando lo mínimo indispensable, y con el cacho de software bajo test acoplado a las entidades relevantes para que funcione como si estuviera en “producción”. Test like you fly, no era? ¿Dónde quedó eso?

6. El desarrollo de software es finito: llamativamente, hay gente que todavía piensa que al hacer una release de software, el tema se terminó y a otra cosa mariposa. Como poder, pueden intentar mentalmente moverse hacia otro proyecto o asunto, pero eso no significa que su relación con ese cacho de software se terminó. El desarrollo de software no termina nunca. Mientras exista una relación laboral activa entre desarrollador y empresa o entre desarrollador y departamento, todo aquel desarrollo hecho por él o ella en ese contexto lo seguirá como una mosca adonde vaya. Porque, una vez que se entrega el software, ¿quien lo mantiene? Si hay que arreglar algo, o agregar algo nuevo, quién lo va a hacer? ¿Una suerte de duende mágico? No es común encontrar duendes con conocimiento de Linux o un nivel decente de C.
   Alguna vez dije en forma algo dramática (para el software de vuelo): la relación desarrollador-software termina cuando el procesador donde corre dicho software reentra en la atmósfera y se evapora.

7. Coding styles: Todo bárbaro con definir cómo nombramos las variables, o dónde ponemos las llaves, si en la misma línea o en la línea de abajo. Pero el gran problema de forzar un estilo es el problema de los estándares en general: quien chequea que se sigan al pie de la letra? Si dependemos de la buena voluntad de la gente, seguramente vamos a terminar con una ensalada de estilos, lo cual es lo mismo a que no haya estilo. Si vamos a usar una herramienta para chequear, ¿quién la configura y mantiene como para que sea consistente? El mejor coding style sigue siendo la vieja máxima de “escribir código como si tu sucesor fuese un psicópata que sabe donde vivís”.

8. Frameworks: Cada segundo que pasa en el mundo, aparece un nuevo framework con nombre hipster. Querés hacer un web server básico en Python y te aparecen 50 frameworks. Un cliente TCP, veinte frameworks más. En JavaScript hay frameworks de frameworks. Hoy en día es imposible encontrar un desarrollador que no venga con un bagaje emocional de frameworks favoritos e intente por todos los medios instalarlos en la agenda.
   La idea del framework se puede llegar a entender: reusar código que es estable y mantenido por una comunidad activa, trayendo consigo funcionalidades que alivian al programador de tareas mundanas de bajo nivel como para que pueda enfocarse en la aplicación. Noble. Pero como suele pasar en cualquier relación, los colores verdaderos se suelen ver en el tiempo. Y cuando uno se da cuenta que el framework A no era lo que queríamos, el nivel de dependencia ya es demasiado alto como para cambiar a framework B, que resuelve exactamente el mismo problema de una forma totalmente diferente por ende hay que aprender todo de nuevo.

9. Malas Herramientas: en el mundo del software, es normal ver gente tomando sopa con un tenedor. Es más: muy probablemente estén muy orgullosos de sus tenedores fabricados de forma casera. Imaginate sentarte en un restaurante y ver que todos toman sopa con un tenedor como si nada; la presión social de cuestionar esa práctica sería tan fuerte que, aún habiendo cucharas, muy probablemente agarremos un tenedor. Mucha gente nota que hay herramientas mal usadas o directamente herramientas horripilantes diseminándose como un virus en la organización, pero la presión de ir en contra de lo “establecido” hace muy difícil cuestionarlas.

10. Documentación estática: desde el momento en que nos nace el buen samaritano y nos aventuramos a documentar algo, aceptamos en los “términos y condiciones” implícitos que la documentación se tiene que mover con el cacho de software que dió origen a dicha documentación. Si algo cambia, la documentación tiene que cambiar. No hay hadas que mantengan la documentación actualizada. Si vamos a ser buenos samaritanos, seámoslo de forma sostenida en el tiempo.
    Y aquellos pensando en tirar el famoso “eL eNfOqUe bAsAdo eN mOdElOs tE rEsUeLvE eSo”, despiértenme cuando el esfuerzo de generar toda esa parafernalia sea menor al esfuerzo de abrir un documento.

Una lectura algo apresurada de estos lastres podría ser: “a Ignacio le gusta el software medio pelo y está en contra de todo lo que lo mejore”. Bueno, si al menos estas cosas fuesen remotamente bien hechas o practicables, tal vez alguna que otra podría aportar cierto valor. Así como están, no son más que un collar de melones.

1. Garbage-in, garbage-out