Climens Codelog

El otro día llegué a un interesante post sobre qué preguntarle a nuestro futuro empleador en una entrevista. Después de leerlo me di cuenta de que si en una entrevista llego a preguntar todo eso y encima valoro las respuestas que me dan, no sé sin encontraría trabajo en el inframundo del desarrollo de software (si trabajas en un sitio que cumple, por ejemplo, 8 de los 12 puntos, por favor ¡contrátame!), por lo menos en España.

Lo importante en definitiva es que se basa en The Joel Test: 12 Steps to Better Code (versión en español). Son 12 sencillas preguntas que esconden toda una filosofía de buenas prácticas deseables en cualquier entorno de desarrollo. También googleando he encontrado un excelente artículo sobre estas 12 preguntas aplicadas al desarrollo web. Estas son:

1. ¿Usas control de versiones?
2. ¿Puedes tener listo el producto en un solo paso?
3. ¿Compilas el producto a diario?
4. ¿Tienes una base de datos de errores?
5. ¿Solucionas los errores antes de escribir nuevo código?
6. ¿Tienes una planificación actualizada?
7. ¿Tienes unas especificaciones?
8. ¿Tienen los programadores un entorno de trabajo tranquilo?
9. ¿Tienes las mejores herramientas que puedes comprar?
10. ¿Tienes testers?
11. ¿Escriben código los candidatos durante su entrevista?
12. ¿Haces pruebas de usabilidad de “vestibulo”? (O sea, a cualquiera que pase por allí y esté dispuesto)

Aunque en realidad se podrían hacer muchas más, si se realizan la mayoría de ellas probablemente se esté trabajando de forma decente. Si no, la cosa se puede poner complicada: posiblemente vives diariamente en un infierno incomprensible.

Ahora toca la parte complicada. ¿Qué nota sacamos en mi empleo actual? Vamos a ver

1. Sí, desde hace un tiempo y por supuesto para nuevos desarrollos. Subversion que no es ni el mejor ni el peor pero tiene herramientas chulas como TortoiseSVN y VisualSVN. Además está bastante extendido y se encuentra fácilmente soporte y ayuda.
2. No, de momento. Es algo necesario y está planificado. Supuestamente con MsBuild o Nant lo podemos conseguir.
3. Sí. Para el producto actual usamos TeamCity con cierto éxito, gratuita para pequeños grupos. Eso sí, faltan aun los scripts completos del paso 2.
4. Sí, usamos Redmine y una herramienta interna (bastante inservible, la verdad), aunque no se si el Redmine me acaba de gustar del todo. En fin, mientras tengamos todos los errores registrados bueno es.
5. Más o menos. A veces el tiempo apremia, pero se debería hacer. La compilación del paso 3 comprueba los tests unitarios, lo que no significa que encuentre todos los bugs, obviamente.
6. Sí, lo intentamos, aunque a veces vamos dando palos de ciego sin saber muy bien el rumbo.
7. Eso creo. El flujo de generación de especificaciones es bastante malo, por lo que muchas veces no son lo suficientemente rigurosas ni explícitas.
8. Depende de la oficina. En la que yo estoy es excelente.
9. No. Siempre hay pegas para adquirir herramientas pero estamos mejorando.
10. No oficialmente. Se prueban las cosas bastante mal y sin rigor.
11. No, lo que me atañe y voy a ver qué puedo hacer al respecto. De momento me leere la Guerrilla Guide to Interviewing a ver qué saco de interesante.
12. No. Parece que ahora quieren contratar a unos expertos en usabilidad para guiarnos, aun así dudo que se realicen pruebas de este tipo

Así que mi JoelScore(tm) es de unos 6/12. Aprobado raspadillo y por los puntos 1, 3 y 4, lo cual no es por tirarme flores, pero creo que he contribuido bastante a instaurar estas herramientas y procesos. A ver si el año que viene llegamos a 8 o 9/12, lo que estaría bastante bien.

En resumen, aconsejo a todo el mundo que trabaja en este mundillo que lea las preguntas, que lea lo que significan las preguntas y se autoanalice para ver en qué estado está y qué puede hacer por mejorarlo.