The Joel Test

En el año 2000, Joel Spolsky (fundador de Stackoverflow)escribió una entrada en su blog titulada «The Joel Test«. Básicamente se hace 12 preguntas sobre cómo está tu proyecto de software. No es matemático, pero como el comenta, se hace en 3 minutos y te puedes hacer una idea (si no la tenias ya hecha). Hoy se me ha ocurrido hacerla con nuestros proyectos (la traducción es libre). Ahora que empezamos con los proyectos en Grails puede ser un buen momento para hacer este test, y ver la situación actual y a donde vamos:

• ¿Tienes sistema de control de versiones? Esta es fácil. La respuesta en nuestro caso es que si, antes CVS y ahora Subversion (pensando si no nos arrepentiremos de no pasar a Git). La cuestión es si lo usamos como es debido, porque no aprovechamos el potencial que nos da para hacer versiones y ramas como debiéramos .
• ¿Puedes construir tu proyecto en un paso? Va a ser que no. Es más, resolver las dependencias de un proyecto suele ser un proceso relativamente largo y manual, con lo que montar un proyecto en un puesto de desarrollo suele alargarse más de lo debido. Es algo que con los proyectos Grails solucionaremos, porque si tienen incorporada la construcción del proyecto.
• ¿Haces versiones diarias? Otra que tampoco cumplimos, en parte por no poder montar el proyecto en un paso. De nuevo con los proyectos desarrollados en Grails podríamos hacerlo más fácilmente, además el plan es montar un servidor de integración continua que nos permita desplegar automáticamente en el ambiente de prueba desde el repositorio.
• ¿Tienes una base de datos de errores? No es exactamente una base de datos de errores, pero tenemos un Redmine funcionando en el que se pueden reportar los errores, básicamente con toda la funcionalidad de un BugTracker tradicional. Como en otras ocasiones, la pregunta es si lo usamos tanto como debiéramos.
• ¿Arreglas los errores antes de escribir código nuevo? Depende de lo grave que sea. De todas maneras en este campo tenemos otros problemas, ya que no tenemos (habitualmente) baterías de pruebas automáticas. Con lo que introducir errores por regresión es algo relativamente fácil. Las razones de esto son culturales mayormente; la idea sería intentar potenciar las pruebas automáticas del software aprovechando las ventajas que Grails nos da, lo que nos proporcionaría mucho mayor control sobre nuestro software, apoyándonos de nuevo en el servidor de integración continua. La idea de todo esto es que cuanto antes detectes el error más fácil será de arreglar (recordaremos más detalles sobre el código en cuestión), con lo que ahorramos tiempo y dinero.
• ¿Tienes un plan puesto al día? Lo intentamos, aunque no es fácil. Esta claro que la planificación es importante, pero la adivinación no conduce a nada bueno. Lo interesante del asunto es tener clara una agenda y poder priorizar en función de los hitos previstos. Se supone que las metodologías ágiles te ayudan con esto, pero está por ver.
• ¿Tienes una especificación (escrita)? Solemos tener la especificación de las aplicaciones escrita, eso no es un problema para nosotros. El problema es cuanto se desvía el producto de esa especificación según va evolucionando el desarrollo, pero ese es otro problema.
• ¿Tienen los programadores condiciones de trabajo silenciosas? No mucho, la verdad. Vamos a dejarlo ahí.
• ¿Tienes las mejores herramientas que el dinero puede pagar? No, pero en esto Joel juega en otra división.
• ¿Tienes probadores? No tenemos probadores dedicados, más alla de otro miembro del equipo que hace esa labor.
• ¿Los candidatos escriben código durante su entrevista (de trabajo? No depende de nosotros, de nuevo Joel juega en otra división.
• ¿Tienes pruebas de usabilidad? No exactamente, pero si hay gente dedicada a mejorar la usabilidad sobre todo de la web corpotativa. Aún así, se puede mejorar mucho en ese terreno.

Se supone que con menos de diez respuestas afirmativas tienes problemas. Aunque eso ya lo sabíamos, y estamos trabajando para mejorar.