Esta es una interpretación personal del magnífico artículo escrito por Joel Spolsky en el año 2000. Joel es uno de los creadores de StackOverflow, y fundador de varias compañías, entre ellas Fog Creek Software, creadora de Trello.

Con el pasar de los años, este test se ha vuelto tan popular que hoy en día se utiliza incluso como carta de presentación de las compañías IT, describiendo de alguna forma el “estado de situación” en cuanto a cómo dicha compañía gestiona los productos tecnológicos. Esta información resulta sumamente útil, entre otros, a los nuevos aspirantes a puestos técnicos, pudiendo comprender de manera simple no sólo cómo funciona la dinámica de trabajo diario, sino además qué nuevas habilidades podrá aprender y qué mejoras podría impulsar una vez incorporado al staff.

El test

Según describe Joel, algo bueno de esta lista es que las respuestas son simplemente un sí o un no, por lo que no es necesario enfocarse en métricas complejas como promedio de errores por día o cantidad de líneas de código escritas. Por otro lado, acepta que dicha lista no debería usarse para medir la seguridad o estabilidad de un software crítico (él cita el ejemplo de una planta nuclear). Se asigna un punto por cada “sí”, siendo 12 el puntaje más alto. También indica que, aunque la mayoría de las compañías tienen un puntaje de 2 o 3, basta con estar por debajo de 10 para inferir que la misma tiene serios problemas, por el simple hecho de que los grandes jugadores (como Microsoft) funciona con un 12 de tiempo completo. Finalmente concluye expresando que lo que persiguen estos doce puntos es lograr un equipo disciplinado que pueda entregar avances de forma consistente.

1. ¿Usan algún mecanismo de control de código fuente?

En un equipo de desarrolladores es necesario poder contar con herramientas que les permitan el trabajo de forma concurrente, consultar qué cambios se hicieron y quiénes los hicieron, revertir un cambio que haya incluido un error o que ya no se desee, y hacer todo esto de forma eficiente y segura.

Hoy en día la mayoría de compañías utiliza GIT, aunque considero que su mero uso no es suficiente, por lo que agrego: 1. la organización debe definir un modelo de gestión de ramas que sea sólido y acorde con la demanda del negocio en cuanto a la frecuencia de entrega y los canales de publicación, así como documentarlo en una base de conocimiento a la que puedan acceder todos los colaboradores, y 2. los desarrolladores deben tener un conocimiento básico sobre la herramienta, que le permita resolver conflictos, integrar cambios y entregar el código sin generar fricciones (vea merge, rebasing y cherry pick).

2. ¿Pueden hacer una compilación en un solo paso?

Mientras más automatizado esté el proceso, menos propenso a fallos será el mismo. Para comprender el enunciado anterior debemos tener en cuenta no sólo los procedimientos cotidianos a los que estamos acostumbrados, sino también las situaciones urgentes (por ejemplo, cuando debemos corregir un error crítico en producción) en las que, si nuestro protocolo de compilación es largo o complejo, probablemente cometamos un error.

Este proceso debería incluir todos los pasos necesarios para que el producto esté listo para ser entregado, así como mecanismos de aseguramiento de calidad, notificaciones a los interesados, etcétera.

3. ¿Hacen compilaciones a diario?

Es común (y frecuente) que un programador introduzca un error en una versión del producto, en la que otros también están trabajando. Esto impide o dificulta el progreso del resto del equipo. Hacer compilaciones a diario (o varias veces al día) ayuda a identificar estos errores.

Hoy en día solemos trabajar con una versión más evolucionada de este proceso, conocida como integración continua, cuyos beneficios son, entre otros, la rápida identificación y corrección de errores, y una mayor seguridad y control del equipo sobre los cambios que han agregado recientemente.

4. ¿Tienen una base de datos de errores?

Es imposible que un equipo y sus miembros retengan en su memoria los errores que deben corregir. Es totalmente necesario realizar un seguimiento formal de los errores que se identifican. Lo mínimo que debe registrar esta base de datos es:

• La serie de pasos completos para reproducir el error;
• El comportamiento esperado;
• El comportamiento actual (incorrecto);
• A quién se le asigna;
• Si se ha arreglado o no.

5. ¿Corrigen los errores antes de escribir código nuevo?

Nota personal: esta pregunta me resulta crucial. Desde mi punto de vista, continuar trabajando en evolutivos de un producto cuando hay errores en producción es análogo a cocinar entre platos sucios; simplemente no puedo hacerlo. Y no es una preferencia personal, sino sentido común: los más probable es que estos errores estén impactando de alguna forma a los consumidores, y por ello a las operaciones de la compañía, es decir, a sus ingresos y su reputación. Creo que es más importante que el usuario pueda utilizar los casos de uso existentes de forma correcta, antes que agregar un nuevo diseño de botones, si los que existen funcionan bien y no hay lugar en el cronograma para atacar ambas cuestiones simultáneamente. Sumado a lo anterior, no es lo mismo intentar encontrar un error en producción si los registros están llenos de alertas y otros errores, a tener dichos registros lo más “limpios” posible. Además, en el caso de tener alguna integración entre nuestra herramienta de monitoreo y algún canal de notificaciones (correo, chat, …) he aprendido que mientras más frecuente es la notificación de errores, menos atención le prestan los miembros del equipo. Curiosamente, son muy pocas las organizaciones que cumplen con este punto.

Ante agendas muy ajustadas y presión por parte de la organización para cumplir con la entrega del producto, se dejan de lado los errores que se han ido acumulando. Joel nos cuenta la anécdota del desarrollo de Microsoft Word y que, tras haber comprendido cómo estos errores afectaron a la calidad del producto, Microsoft adoptó una “metodología de cero defectos”, que consiste en que la máxima prioridad es eliminar los errores antes de escribir cualquier código nuevo, debido a que:

• En general, cuanto más espere antes de corregir un error, más costoso (en tiempo y dinero) será corregirlo, debido a que esta corrección será fácilmente abordada por el autor del error, ya que es quien estuvo trabajando recientemente en ello. Mientras más pasa el tiempo, más costoso será para la empresa corregir este error.
• Es más fácil predecir cuánto tiempo llevará escribir código nuevo que corregir un error existente; esto significa que si tiene un cronograma con muchos errores pendientes de corregir, el cronograma no es confiable, pero si ha corregido todos los errores conocidos y todo lo que queda es código nuevo, entonces su programación será asombrosamente más precisa.
• Puede responder mucho más rápido a la competencia; si su competidor presenta una característica nueva que está robando a sus clientes, puede implementar sólo esa característica y enviarla en el acto, sin tener que corregir una gran cantidad de errores acumulados.

6. ¿Tienen un cronograma actualizado?

• Aunque a algunos no les guste, los cronogramas son clave para la planificación del negocio: presentaciones, rondas de inversión, publicidad, etc.
• El cronograma obliga a decidir qué funciones va a hacer, y luego lo obliga a elegir las funciones menos importantes y cortarlas en lugar de caer en featuritis (también conocido como “arrastre de alcance”).

Para lograr mantener un cronograma sin dolor, Joel nos recomienda en otro artículo usar herramientas simples, explotar las funcionalidades en una serie de tareas, y destaca la importancia de la participación de los programadores en la estimación y planificación de estas tareas, así como mantener las estimaciones originales y las actuales, y considerar las ausencias y vacaciones en dicha planificación, entre otros consejos fundamentales.

7. ¿Escriben especificaciones?

En este caso, sólo citaré algunas frases textuales, dado que no podría describirlo mejor:

• Escribir especificaciones es como usar hilo dental: todos están de acuerdo en que es algo bueno, pero nadie lo hace.

• En la etapa de diseño, cuando descubre problemas, puede solucionarlos fácilmente editando unas pocas líneas de texto. Una vez que se escribe el código, el costo de solucionar los problemas es dramáticamente más alto, tanto emocionalmente (la gente odia tirar el código) como en términos de tiempo, por lo que hay resistencia a solucionar los problemas. El software que no se creó a partir de una especificación generalmente termina mal diseñado y el cronograma se sale de control.

• Debe hacer cumplir una regla simple: “no hay código sin especificaciones”.

En mi experiencia personal, cada minuto invertido en escribir una especificación nos ha ahorrado a mí y mis equipos varios minutos e incluso horas de desarrollo, ya que ésta nos ha permitido reflexionar de forma temprana y con una visión de alto nivel qué alcance, costo e impacto tendría la solución.

8. ¿Los programadores tienen condiciones de trabajo tranquilas?

Los trabajadores del conocimiento trabajan mejor entrando en “ritmo”, también conocido como estar “en la zona”, donde están completamente concentrados en su trabajo y completamente desconectados de su entorno. Pierden la noción del tiempo y producen grandes cosas a través de la concentración absoluta. Esto es cuando hacen todo su trabajo productivo. Escritores, programadores, científicos e incluso jugadores de baloncesto te hablarán sobre estar en la zona.

El problema es que entrar en “la zona” no es fácil. Lleva al menos 15 minutos comenzar a trabajar con la máxima productividad. A veces, si está cansado o ya ha hecho mucho trabajo creativo ese día, simplemente no puede entrar en la zona y pasa el resto de su día de trabajo jugando, leyendo la web, etcétera.

El otro problema es que es muy fácil que te saquen de la zona. El ruido, las llamadas telefónicas, salir a almorzar, las interrupciones de los compañeros de trabajo y cualquier otra distracción (especialmente las interrupciones de los compañeros de trabajo) te sacan de la zona. Con los programadores, esto es particularmente negativo. La productividad depende de poder hacer malabarismos con muchos pequeños detalles en su memoria a corto plazo, todos a la vez. Cualquier tipo de interrupción puede hacer que estos detalles se desvanezcan. Cuando reanudan el trabajo, no pueden recordar ninguno de estos detalles y tienen que volver a buscar y analizar estas cosas, lo que los ralentiza, a veces un poco, a veces mucho.

Por lo anterior, es clave que los programadores y demás colaboradores creativos tengan un espacio en el que se sientan a gusto y minimizar las interrupciones, como reuniones o llamadas innecesarias o que puedan esperar.

He tenido una experiencia laboral en la que, por día, no tenía menos de 8 reuniones, todas ellas de al menos media hora (planificación, nuevos proyectos, sesiones de pair programming, reporte a gerencia, …). En un momento, el gerente del proyecto me preguntó por qué escribía menos código en relación con mis desarrolladores, siendo yo el líder técnico. Esto, a pesar de que dedicaba los fines de semana para hacer estas labores que no podía cumplir durante mi horario laboral. Muchas veces es difícil lograr que el personal ejecutivo se ponga en tus zapatos. Es por ello que considero que este punto es uno de los más importantes y al mismo tiempo más complejo de implementar, ya que implica un cambio cultural y require instruir al personal sobre las incumbencias de cada rol. Las compañías que no se suban a este proceso de transformación cultural corren un alto riesgo de convertirse en un ambiente tóxico para sus miembros.

9. ¿Utilizan las mejores herramientas que el dinero puede comprar?

Resumiré este punto con la siguiente frase: si la compañía quiere un producto de calidad, entonces provean a sus equipos insumos y recursos de calidad. Los mejores que puedan comprar.

• Buenos equipos: recuerden que para los programadores un equipo de oficina no es suficiente. Necesitan de máquinas con más memoria, procesador y almacenamiento. Esto se debe a que los entornos de desarrollo así lo requieren. El no satisfacer este aspecto resultará en ciclos de desarrollo más lentos y mayor frustración de los desarrolladores. No es lo mismo esperar 5 segundos para realizar una prueba, que esperar 60 segundos o más. Y un programador realiza cientos, miles de pruebas por día. Una pantalla adicional siempre es bienvenida.
• Licencias de software: si quieres un sistema con algún componente propietario (base de datos, plataforma, …), deberás pagar por él y asegurarte que todos tus desarrolladores tengan en su entorno local las prestaciones lo más cercanas posibles al entorno de producción. Este es un costo adicional que normalmente no es contemplado en el plan de proyecto original.

Y me siento en la obligación moral de preservar esta frase de Joel: Los equipos de desarrollo de primer nivel no torturan a sus programadores. Incluso las frustraciones menores causadas por el uso de herramientas de poca potencia se suman, lo que hace que los programadores se sientan malhumorados e infelices. Y un programador gruñón es un programador improductivo. Para agregar a todo esto… los programadores son fácilmente sobornados al darles las cosas más interesantes y más novedosas. ¡Esta es una forma mucho más económica de hacer que trabajen para usted que pagar salarios competitivos!

10. ¿Tienen evaluadores (testers)?

Si su equipo no tiene evaluadores dedicados, al menos uno de cada dos o tres programadores:

• O bien está enviando productos defectuosos,
• o está desperdiciando dinero al hacer que los programadores de $100/hora hagan un trabajo que pueden hacer los evaluadores de $30/hora.

Aunque entiendo lo que Joel expone, pienso que una opción intermedia sería que, al menos, no sea el mismo autor del cambio quien lo someta a prueba. Sin embargo, en términos económicos, creo que el punto es irrefutable.

11. ¿Los nuevos candidatos escriben código durante su entrevista?

¿Contratarías a un mago sin pedirle que te muestre algunos trucos de magia? Por supuesto que no. ¿Contratarías un servicio de catering para tu boda sin probar su comida? Lo dudo.

En lugar de sólo basarse en el currículum del candidato, tomar entrevistas de estilo “trivia” o peor aún, hacer preguntas tan rebuscadas que su respuesta es imposible de inferir, haz que el candidato escriba un poco de código, ya que a fin de cuentas es para lo que los contratarás.

12. ¿Hacen pruebas de usabilidad en los pasillos?

Una prueba de usabilidad de pasillo es donde tomas a la siguiente persona que pasa por el pasillo y la obligas a intentar usar el código que acabas de escribir. Si le hace esto a cinco personas, aprenderá el 95% de lo que hay que aprender sobre problemas de usabilidad en su código.

Este punto está enfocado en las interfaces de usuario y la experiencia de usuario. No se refiere a que realmente te pares en el pasillo y aceches a tus compañeros para que usen tu funcionalidad, sino a tomar a gente no involucrada en la misma (unas pocas, con 5 o 6 es suficiente) y les pidas que que hagan una devolución.

Algunas compañías involucran a los usuarios mediante programas de pre-lanzamiento, pruebas A-B. Otras simplemente le piden a algunos colaboradores de otros equipos que destinen 5 minutos para dar su opinión al respecto. Desde luego que esta prueba se puede llevar a cabo con una maqueta en lugar de la versión final, para volver al tablero y realizar los ajustes pertinentes antes de su implementación, la cual será más costosa.

• Joel Test