Si hay un tema que realmente me apasiona pues es la Ingeniería de Software. Por supuesto, no soy un experto en el tema, pero sí suelo pasarme algún tiempo leyendo y curioseando cosas interesantes al respecto cuando me da el tiempo. Revisando mis viejos archivos, encontré el link a un artículo que Joel Spolsky publicó hace años ya y que me había propuesto comentar en este blog, aunque por falta de tiempo no había podido hacerlo.
Quisiera entonces comentarles acerca del Test de Joel. Este es un test sencillo de 12 preguntas que sirve para medir la calidad del equipo de desarrollo y que Joel extrajo de un texto más extenso elaborado por el Software Engineering Institute. Mi objetivo en este post no es el traducir el Test de Joel, que por cierto lo pueden encontrar completo y con toda su explicación por acá, sino más bien el hacer un énfasis y dar un jalón de orejas a la mayoría de las empresas de desarrollo y departamentos de sistemas. Por su puesto, yo no me excluyo, pues la empresa para la que trabajo tampoco podría sacarse el más alto puntaje posible (aunque estamos cerca).
El test es simple, le das 1 punto a cada pregunta contestada afirmativamente. Sacar 12 es fabuloso, 11 es aceptable, pero si sacas 10 o menos estás en serios problemas. Voy entonces a ir comentado una a una cada una de las preguntas. Puedes ir sacando tu puntaje a la vez que vas reflexionando entorno a cómo se desempeña tu empresa en cada uno de los aspectos.
1. ¿Usas control de código?
Nadie está exento de cometer errores y por ende eventualmente vas a rogar el poder volver a una versión vieja de tu aplicación, la cual funcionaba a las mil maravillas. Tu sistema de control de código te permitirá hacer esto e incluso te permitirá comparar archivos y líneas específicas de código para determinar en qué punto se produjo algún cambio que provocó el comportamiento actual de la aplicación. Más aún, cuando son dos ó más personas las que trabajan en un mismo proyecto, se vuelve esencial el tener una forma rápida, práctica y transparente de obtener los últimos cambios al código fuente que realizaron tus compañeros y sin los cuales tal vez no puedas ejecutar bien la aplicación. Trabajar sin control de código es un verdadero dolor de cabeza.
2. ¿Puedes hacer un build de un solo paso?
Hacer un build puede ser tan sencillo como crear un proyecto de instalación de Visual Studio, agregarle el exe y las dll de tu aplicación y mandarlo a generar. Sin embargo, esto solo te funcionará para los casos más simples, pues para la mayoría de aplicaciones comerciales el proceso de instalación involucra el extraer la última versión del fuente del sistema de control de código, determinar y asignar el número correcto de versión a cada componente de la aplicación, regenerar los dll y exe de toda la aplicación, correr las pruebas unitarias, preparar los archivos de configuración para el usuario final, generar el instalador, colocar el instalador en un lugar accesible a todos los miembros del equipo, entre otras cosas.
Tratar de hacer todo esto cada vez que tienes que preparar un nuevo build para tu jefe, para los de control de calidad ó para el mismo cliente, es todo un dolor de cabeza y es muy, pero muy propenso a errores. Lo digo por experiencia, este proceso tiene que ser 100% automático y no deberías de dar más de un click o un enter para que todas estas tareas de ejecuten de manera secuencial y automática. Caso contrario, tendrás constantes demoras para lograr liberar una nueva versión de tu aplicación y esto se volverá más lento justo en el momento en que necesitas más rapidez para entregar tu producto a tiempo.
3. ¿Haces builds diarios?
Nunca falta uno. Son las 5:30pm, ya te estás preparando para ir a casa. Mientras, tu colega de al lado ha terminado su tarea de hoy un tanto al apuro porque tiene que irse de urgencia a atender otras ocupaciones y le da check-in a su código del día si siquiera compilarlo. Con el check-in, el código está ahora a tu disposición, y en un último check-out del día, en el que te traes todo el código (ó una parte del código) de tus colegas, viene ese código que no fue compilado y, ohh sorpresa, ahora tu propio código ya no compila. Qué puedes hacer? Pues nada, tu amigo ya se fue y no volverá hasta el otro día.
Para prevenir esto se usan los builds diarios, lo cual consiste en hacer un build todos los días que incluya el último código que ingresaron todos los desarrolladores. Puede ser al medio día ó durante la noche, como proceso automático. La idea es que, una vez que se detecta que hay un error de compilación, quien lo dañó (o quienes lo dañaron) pues lo arregla de inmediato. Así, todo mundo sabe que, una vez que el build diario compila, todos pueden hacer un check-out de la última versión del código sin temor alguno.
4. ¿Tienes una base de datos de bugs?
Una vez más, todos nos equivocamos. No hay desarrollador que pueda escribir un código perfecto en una sola tanda, sin un solo error. Tu código va a tener bugs y eso es definitivo. Lo que debes preguntarte es cómo vas a hacer para llevar un control coherente de todos esos bugs que vayan saliendo. Lo ideal es tener una base de datos donde pongas todos los bugs ó un sistema que se encargue de esto. Pero, lo mínimo que debes tener por cada bug, es pues los pasos para reproducirlo, el comportamiento esperado, el comportamiento observado, a quién está asignado y su estado actual (activo, resuelto, cerrado, etc).
Esta base de bugs tiene un valor increíble en el proceso de desarrollo, pues por un lado es una medida bastante clara de qué tan estable está el sistema en un momento dado, mientras más detallados sean más fácilmente lo puede corregir el desarrollador, se puede determinar si los bugs aparecen por errores en las especificaciones ó por errores constantes de algún desarrollador, etc. La base de bugs es sumamente últil y es un componente fundamental en el aseguramiento de la calidad del software.
5. ¿Corriges los bugs antes de escribir nuevo código?
¿Qué haces cuando te reportan que hay un error en la aplicación? ¿Lo corriges inmediatamente o lo dejas nomás en la lista para corregirlo luego, pues tienes nuevas funcionalidades que implementar aún? En lo personal, yo he seguido el segundo enfoque hasta ahora. ¿Por qué? Pues porque tengo un cronograma que tengo que cumplir y muchas veces no me da el tiempo para ir corrigiendo cada cosa que aparezca.
¿Por qué está mal esto? Simple: Mientras más tiempo dejes pasar desde que apareció el bug, más difícil se te va a hacer el corregirlo. A menos que tengas una super memoria, es muy probable que si tratas de corregir un bug de hace 1 mes se te haga bastante difícl corregir, simplemente porque ya no recuerdas bien esa porción de código en la que se produjo el bug. En cambio, si el bug ocurrió hace solo unas horas, es probable que el código esté fresco en tu mente y podrás corregir el bug sin problema.
Me apunto un cero en esta pregunta, pues apenas si estoy aprendiendo la importancia de atender los bugs a tiempo.
6. ¿Estás al día con tu cronograma?
Soy desarrollador y ¡detesto los cronogramas! Sin embargo, son necesarios. Aunque a uno como desarrollador le gustaría tener todo el tiempo del mundo para implementar un código perfecto, la gente de negocios necesita desesperadamente el tener un cronograma al día y bien definido para ellos poder hacer también su planificación de actividades, como las demos, presupuestos, etc. Más aún, el cronograma te ayuda a definir cuáles características de la aplicación entrarán en la versión actual y cuáles otras, de menor importancia, se pueden relegar para una futura versión. Sin un buen cronograma, probablemente te matarás tratando de cumplir todos los requerimientos del usuario para "ayer" y nunca lograrás terminar ninguno bien hecho.
En este punto insisto, el jefe de proyecto juega un rol importantísimo aquí, pues es él quien debe llevar control del avance del cronograma y de su buen cumplimiento. Por supuesto, cada desarrollador debe ser responsable y cumplir sus tareas a tiempo, pero solamente el jefe del proyecto es quien sabe en qué punto el proyecto se empieza a salir de control y es quien tiene la autoridad y el conocimiento para dividir algún requerimiento ó postergarlo para otra versión ó tal vez para asignar más recursos a una parte del proyecto que se está quedando relegada. Si el jefe del proyecto se descuida, eventualmente el cronograma correrá grave riesgo y aún cuando todos los desarrolladores estén luchando por cumplir sus tareas, puede ya ser muy tarde para volver al ritmo correcto.
7. ¿Tienes especificaciones claras?
Una vez más, soy desarrollador y ¡detesto escribir especificaciones funcionales! Afortunadamente, no tengo por qué hacer esto, justamente porque soy desarrollador, no jefe de proyecto ni analista de negocios. Es esencial que alguien del equipo se enfoque meramente en la redacción de especificaciones funcionales claras y bien detalladas. La redacción debería ser tal que, cualquier desarrollador que coja ese documento debería lograr entenderlo de una vez y tener una buena idea de cómo empezar a diseñar la solución.
Es esencial que todas las compañías de desarrollo designen a alguna persona del equipo para que asuma este rol, pues cuando se lo suelen dar a los desarrolladores (típico en empresas pequeñas) éstos difícilmente podrán producir especificaciones que realmente satisfagan lo que necesita el cliente, sino que más bien tratarán de escribir lo más sencillo y conciso para terminar el documento rápido y/o para no tirarse ellos mismos un requerimiento lleno de reglas de negocio difíciles de implementar.
8. ¿Tienen los desarrolladores condiciones de trabajo silenciosas?
¡¡¡Silencio, silencio!!! Las clásicas conversaciones sobre las últimas noticias en las primeras horas de la mañana, la camaradería antes y después de salir al almuerzo, la ronda de chistes y burlas a media tarde y los comentarios de cierre de día antes de la hora de salida, son clásicos en todo lugar donde he trabajado incluso hasta el día de hoy. Más aún, las clásicas preguntas de tus colegas sobre "¿cómo hago esto?" ó "¿tienes un código para hacer esto de acá?" ó "¿te ha pasado esto?", nunca faltan. Y qué decir de la ronda de MP3 a todo volumen del DJ del equipo? ¡Y el teléfono que no deja de sonar!
Todo este tipo de cosas son mortales para la productividad de un desarrollador. Está comprobado que, normalmente, al desarrollador promedio le toma hasta 15 min el entrar en productividad, es decir, concentrarse y enfocarse en su tarea. Pero si encima de ello ocurren interrupciones como las que acabo de describir, es posible que el desarrollador se tome hasta media hora en volver a su concentración.
Algo clave a este respecto es el no sentar a los desarrolladores uno al lado del otro. Si pones a dos personas a trabajar muy cerca sin ningún tipo de separación, al menos una de ellas eventualmente iniciará una conversación, que no necesariamente será por cuestiones del trabajo o proyecto actual. Sin embargo, si se les coloca en oficinas separadas, de seguro que será más la pereza de levantarse del asiento para ir a la otra oficina que las ganas de conversar el último chisme al compañero ó de preguntarle algo que, buscándolo en Internet, no tomaría ni 15 segundos resolver.
9. ¿Usas las mejores herramientas que se puede comprar?
Jefe de Desarrollo: "Esa nueva Dell con 2GB en RAM e Intel Core 2 Duo de 2Ghz sería una maravilla para los desarrolladores"; Gerente: "Estás loco? Compra nomás un clon de 512Mb y Pentium 4, más que suficiente y más barato". Este tipo de decisiones se toman a diario, buscando precautelar el gasto por encima de todo. Sin embargo, todos sabemos que una máquina que no compile rápido el código ó que esté sufriendo constantemente fallos porque la memoria "salió mala" es una pérdida de tiempo considerable y que, al ser constante (8 horas x 5 días a la semana) representa una demora increíble en el tiempo que le toma al desarrollador el terminar sus tareas. Lo mismo pasa cuando necesitamos hacer una pantalla con un grid que haga mil maravillas y sabemos que el grid de Infragistics es perfecto para la tarea y nos ahorraría varios días y semanas de programación, pero como no hay "presupuesto" para comprarlo, pues simplemente nos mandan a usar el grid incluido en la herramienta de desarrollo, el cual probablemente carezca de docenas de características avanzadas.
Siempre que sea posible hay que optar por darle al desarrollador el mejor hardware y el mejor software que exista para que realice sus tareas. Sin buenas herramientas, el desarrollador se demora; si se demora, se desmotiva; y si se desmotiva, se vuelve improductivo. Y créanme, no hay nada más perjudicial en un equipo de desarrollo que un desarrollador improductivo. Eso sí que causa un gravísimo daño al avance del proyecto.
10. ¿Tienes testers?
Aunque parezca increíble, la gran mayoría de empresas de desarrollo aún piensan que contratar gente exclusivamente para que haga las pruebas (los testers) es más un lujo que una necesidad, un asunto de baja prioridad. No hay nada más lejos de la verdad. Señores gerentes y jefes de proyecto: ni el más excelente de sus desarrolladores podrá producir un código de 100% de calidad, aún si ellos lo intentaran con todas las ganas del mundo. Ya el hecho de implementar el código más eficiente posible, hacerlo mantenible, asegurarse de poner todas las reglas de negocio, hacer todas las validaciones, documentar el código, hacer el correcto diseño de clases, refactorizar, etc, es suficiente trabajo como para que encima les soliciten que no se olviden de todas las otras 500 reglas de negocios y procesos que son afectados por los nuevos requerimientos que les pasaron.
El desarrollador es técnico y su preocupación es la de cumplir los requerimientos en el tiempo dado y con la menor cantidad de errores posible. El tester es en cambio el gran conocedor de la forma como debería operar la aplicación, en términos ya no técnicos, sino funcionales. Él sabe qué es lo que le agrega valor a la aplicación, qué es lo que definitivamente no debe fallar y qué cosas adicionales pueden realmente agradarle al cliente. Más aún, el tester es un experto en el arte de encontrar errores de todo tipo en la aplicación, pues existen docenas, sino centenares de técnicas a su disposición para atrapar hasta al bug más esquivo.
Los testers SON INDISPENSABLES y tienen exactamente el mismo nivel de importancia y peso en la construcción de la aplicación que los desarrolladores ó los jefes de proyecto. Si quieres calidad, siempre ten un tester a tu lado. Al principio es un poco molestoso, pero a la larga será tu mejor amigo, pues ayudará a que tu software realmente se luzca cuando llegue a manos del cliente.
11. ¿Los nuevos candidatos escriben código durante su entrevista?
Este error es tanto o más común que el tema de los testers. Es muy típico, aún hoy en día, que las compañías de desarrollo contraten a su nuevo personal basándose en una simple entrevista en la que se discuten sus estudios, habilidades, trabajos previos y expectativas diversas. Mientras más impresione el candidato con su diálogo, más probabilidad tiene de ser contratado.
Esto es un grave error, pues lo mínimo que se le debe aplicar a todo desarrollador es una prueba en la que se le ponga a escribir código, puesto que es la única forma de saber qué tan capaz será de escribir buen código, con la mejor calidad posible, en el menor tiempo posible y estando bajo presión. No tiene que ser nada del otro mundo, un simple problema como "implementa la función Factorial" ó "encuentra cuántas veces se repite esta cadena en el siguiente párrafo" es más que suficiente para darte una buena idea de la calidad de código que puede escribir el candidato. Preguntas enigmáticas como "dime cuántas sobrecargas tiene el método Compare y en qué orden va cada parámetro" están totalmente fuera de lugar y no aportan nada al proceso.
Importante en este punto es también el asegurarse que TODOS los miembros actuales del equipo de desarrollo aprueben y acepten al nuevo candidato. Si el candidato no convence a por lo menos uno de los miembros actuales del equipo de desarrollo (por razones justificadas claro está), el candidato no puede entrar. La opinión negativa y justificada de cualquier miembro del equipo acerca del candidato debe ser suficiente para dar a entender que aquel no es la mejor opción para el cargo.
12. ¿Haces pruebas de usabilidad?
Esta es una buena práctica que consiste en llamar a la primera persona que atraviese el pasillo y pedirle que pruebe el sistema que acabas de hacer. Está comprobado que si haces esto con al menos cinco personas, descubrirás rápidamente los mayores problemas que el usuario común tiene con la aplicación.
Conclusión
Como lo dije al inicio, sacar 10 ó menos en este test, denota un grave problema en tu compañía de desarrollo. Lo bueno de este test es que te ayuda al menos a identificar problemas que tú ni pensabas que existían. Es momento entonces de tomar la iniciativa y buscar formas de mejorar las áreas en las que hay falencias. Aún si eres desarrollador, de aseguro tus jefes agradecerán les hagas conocer los resultados de este test y las medidas correctivas que se pueden tomar. Mejorar el desenvolvimiento del equipo de desarrollo es crucial para lograr producir software de mucho mejor calidad y en mucho menor tiempo.