A través de su otra empresa Fog Creek Software,  Joel está también detrás de muchos otros productos como  FogBugz, Trello, and Gomix.

Joel Spolsky es uno de los personajes más conocidos e influyentes en el mundo del desarrollo software.  Hoy en día es conocido sobretodo por ser el fundador y CEO de StackOverflow (ya sabéis, la Meca de todo programador) pero Joel también se ha hecho conocido por su blog “Joel on Software” donde habla de todos los aspectos relacionados con el desarrollo de software en base a su experiencia como fundador de startups tecnológicas.

Después de trabajar con los equipos que crearon todos estos productos, Joel llegó a la conclusión que había una serie de patrones o “best practices” que todo equipo de desarrollo debería seguir para producir código robusto y de calidad.

Es lo que él llamó el “test de Joel”. Lo publicó por primera vez en el año 2000 pero sigue siendo tan válido hoy como entonces (no sé si eso nos deja en muy buen lugar 🙂 ). De hecho, Joel lo tiene en su top 10 particular como lectura obligada para todos los que lleguen a su página.

Es un test de 12 preguntas que se pueden contestar fácilmente con un Sí o un No. Un punto por cada Sí. Si sacas un 12 perfecto. Un 11 es aceptable pero si sacas 10 o menos, tu equipo de desarrollo tiene serios problemas y deberías buscar ayuda. Las grandes empresas, como por ejemplo Microsoft, están en el 12.

Fíjate que, gracias a los avances tecnológicos, hay algunos puntos que son casi regalados (como el primero, con GitHub, GitLab y cia, nadie tiene la excusa de no utilizar un control de versiones) pero aún así me temo que la gran mayoría de vosotros estaréis en la zona de peligro.

¡Haz el test y dinos qué puntuación sacas!

Las 12 preguntas del test de Joel para evaluar la calidad de un equipo software

Utilizas un control de versiones?

Me atrevo a decir que si contestas no a ésta, apaga y vámonos. No hace falta ni que sigas con el test. En su lugar, créate una cuenta en GitHub y empieza de nuevo.

¿Puedes generar una versión de la aplicación en un sólo paso?

¿Puedes hacer un “build” de tu aplicación a partir de la última versión del código apretando un botón? ¿O tienes que ejecutar 20 scripts diferentes uno detrás de otro para llegar a “algo” que se pueda desplegar en el servidor?

En el año 2000, esto podía tener una cierta dificultad técnica. A día de hoy, no hay tampoco excusa para no configurar un proceso de integración continua (por ejemplo, con Jenkins o Travis, integrado en GitHub) que lo haga.

¿Generas una nueva versión cada día?

No hace falta que después esa versión se haga pública pero hacer un “daily build” ayuda a detectar errores en el código o su integración. Las mismas herramientas de integración continua del punto anterior detectan errores de compilación, dependencias,… que un programador puede haber descuajaringado al modificar el código. No esperes al día de la release de la nueva versión para encontrar estos problemas. Asegúrate que cada día la aplicación está lista para usarse. Esto también te permitirá reaccionar más rápido a los cambios del mercado.

¿Tienes una base de datos con todos los bugs?

Muchos programadores creen que pueden recordar perfectamente todos los bugs pero, siendo sinceros, en nuestra cabeza no hay sitio para más de 2-3. Hay que listar formalmente todos los bugs de la aplicación y hacerlo de una forma estructurada, incluyendo como mínimo, para cada bug:

  • pasos para reproducir el bug
  • comportamiento esperado
  • error observado
  • quién está encargado de solucionarlo
  • estado del bug (arreglado, en proceso,…)

Una vez más, programas para gestionar los bugs hay muchos (y gratuitos), como Bugzilla, pero no basta con instalarlos, ¡hay que usarlos!

¿Arreglas primeros los bugs conocidos antes de escribir código nuevo?

La presión para acabar el proyecto provoca que los bugs se vayan acumulando mientras añadimos código como locos para cumplir los plazos del proyecto. La idea es que los bugs ya se corregirán al final. Y luego pasa lo que pasa.

Mucho mejor adoptar una metodología de “cero bugs”, donde la prioridad es siempre eliminar los bugs conocidos. A la larga acabarás antes.

¿Actualizas tu planificación?

Los informáticos somos muy malos estimando el coste y la duración de un proyecto. Y en muchos casos esas estimaciones las hacen comerciales que buscan vender el proyecto como sea aunque los plazos sean irrealizables.

Es muy importante que el equipo lleve su propia planificación y la actualize a menudo para tener una visión clara de en qué punto del proyecto están y cuanto falta, realmente, para la finalización.

¿Tienes una especificación del proyecto?

Escribir especficaciones es como usar el hilo dental, todo el mundo está de acuerdo en qué es muy importante pero a nadie le gusta hacerlo.

La tendencia de todo programador es decir que “su” especificación es el código.  Pero es mucho más fácil y barato detectar problemas en la especificación que esperar a qué el código este listo para darse cuenta de qué lo que se ha desarrollado no es lo que se pedía.

¿Pueden trabajar tranquilos los programadores?

Muy importante. Puedes tener los mejores programadores del mundo pero si no tienen un espacio adecuado para trabajar y un entorno libre de interrupciones van a producir código basura.

Después de cada interrupción (aunque sea muy corta, de tan sólo un minuto), tardamos media hora en volver a concentrarnos.

Sí, ya sé que están muy de moda los open space y es muy “cool” tener uno, pero, creede, es una moda que está haciendo mucho daño.

¿Compras las mejores herramientas?

Lo barato sale caro. Tu bien más preciado es el tiempo de tu equipo. Si ahorras en la potencia de las máquinas, los IDEs, librerías,… acabarás pagando mucho más en tiempos de espera, errores no detectados,…

Y, además, tienes el riesgo que se cansen y vayan a trabajar a la competencia en busca de mejores condiciones.

¿Tienes testers?

Todo equipo debería tener personas encargadas exclusivamente de testear la aplicación. Al menos uno para cada 2-3 programadores.

¿Pides a los candidatos que escriban código durante el proceso de contratación?

Igual que no contratas un artista sin escucharlo/verlo primero, no contrates un programador sin evaluar su capacidad para escribir código. Hoy esto es una práctica estándar en casi todas las grandes empresas (hay hasta libros de preparación para el tipo de código que te hacen escribir en Google!) pero no tanto en empresas más pequeñas.

Y si no le quieres hacer un examen “live”, como mínimo asegúrate de mirar bien sus repositorios públicos y contribuciones en GitHub.

¿Tienes una política de tests de usabilidad?

No basta con testear la calidad del código. Hay que evaluar también la usabilidad del producto. Cada cierto tiempo deberías hacer un “hallway usability test”. Es decir, coger a alguien que pase por el pasillo, enseñarle tu producto y ver como reacciona a él (¿sabe o no utilizarlo? ¿En qué partes del programa se pierde? ¿qué preguntas te hace?…).

Ya sabes que lo único que necesitas saber acerca de las instrucciones es que nadie las va a leer. La UI debe ser autoexplicativa.

Si has llegado hasta aquí y tienes ganas de aprender más cosas que deberías (o no) hacer para mejorar tu trabajo como programador, te recomiendo que leas también el libro (gratuito) 97 cosas que todo programador debería saber (eso sí, está en inglés) y repases los falsos mitos de la programación.

Imagen destacada gracias a Jake Hills vía Unsplash