12 pasos para programar mejor

Como puede verse en los links de este blog, uno de los sitios que frecuento es el blog de Joel.

Hace varios años escribió un artículo sobre cómo evaluar si se están usando buenas prácticas para desarrollar software. Me pareció tan interesante que en esta oportunidad voy a traducir partes del artículo y modificarlo para reflejar mis opiniones. Más allá de alguna ironía que pueda usar, deben saber que me considero desde siempre un programador (aunque ahora esté algo oxidado), así que cuando hablo de programadores también me refiero a mi persona :-)
12 pasos para programar mejor

¿Alguna vez escucharon hablar de SEMA? Es un sistema bastante esotérico para medir cuan buenas son las prácticas utilizadas por un equipo de desarrollo de software. No, esperen! No sigan ese link! Les tomará cerca de 6 años entenderlo. Por eso Joel ha desarrollado su propio – y simplificado – test para evaluar la calidad de un equipo de desarrollo. La parte buena de esto es que lleva solo unos minutos entenderlo. Me tomaré el atrevimiento de modificarlo para reflejar también mis puntos de vista.

El Test de Joel (levemente modificado):

  1. Estás usando adecuadamente una herramienta de control de versiones?
  2. Podés realizar una implementación en un solo paso?
  3. Cada programador actualiza diariamente su versión local de desarrollo?
  4. Tenés una herramienta para registrar y administrar los bugs?
  5. Aprovechás todas sus oportunidades para arreglar los bugs existentes al escribir código nuevo?
  6. Contás con un cronograma de trabajo actualizado?
  7. Escribís especificaciones antes de desarrollar cualquier funcionalidad?
  8. Los programadores tienen un ambiente de trabajo adecuado?
  9. Usás las mejores herramientas de desarrollo que el dinero puede comprar?
  10. Tenés un equipo de testers independiente del equipo de desarrollo?
  11. Cuando se evalúan nuevos postulantes, les pedís que escriban código durante la entrevista?
  12. Realizás tests de usabilidad?

La parte interesante de este test es que es muy simple contestar con un SI o NO a cada pregunta. No hay que ponerse a evaluar cantidad-de-líneas-de-código-escritas-por-día o promedio-de-bugs-por-implementación. Dale a tu equipo 1 punto por cada SI y listo.

La debilidad de este test es que realmente no debería utilizarse para asegurarse que el software usado en una planta nuclear es seguro.

Un puntaje de 12 es perfecto, 11 es tolerable, pero 10 o menos implica que uno está en problemas. La verdad es que la mayoría de las organizaciones logran un puntaje menor a 5, por lo cual están en serios problemas y necesitan ayuda… porque compañías como Microsoft trabajan con un puntaje de 12 todo el tiempo.

Por supuesto estos no son los únicos factores que determinarán el éxito o fracaso. En particular si se tiene un excelente equipo de desarrollo trabajando en un producto que nadie quiere… bueno… la gente simplemente no va a interesarse en ese producto. Y también es posible imaginarse un equipo de “temerarios” que no hagan nada de todo esto, pero incluso así logren producir un software excelente, que cambie el mundo. Pero descartando esos factores, si se obtienen esos 12 puntos, se logrará tener un equipo disciplinado que consistentemente cumplirán sus entregas.

Recomendaciones para cada punto:

  1. Estás usando adecuadamente una herramienta de control de versiones?
  2. Se puede optar por varias herramientas de control de versiones que son gratuitas, como CVS o SVN (también hay herramientas pagas como Microsoft Source Safe). Sin ningún tipo de control de versiones es muy difícil que varios programadores sepan exactamente qué cambio está haciendo el otro. Cuantas más personas tiene un equipo de desarrollo, más importante se hace tener este punto resuelto. Sin una herramienta de control de versiones, los errores que un programador cometa no pueden volverse fácilmente atrás. Mal utilizada la herramienta, es posible que el esfuerzo de compaginar distintos proyectos que son desarrollados en paralelo sea comparable al esfuerzo del desarrollo en si mismo. Esto no está bien. Mi recomendación es instalar una herramienta de control de versiones, y de las que he utilizado, sugiero el SVN.

  3. Podés realizar una implementación en un solo paso?
  4. Con este punto se debe medir cuántos pasos se deben realizar para lograr implementar la última versión del software en algún ambiente (testing, producción, etc.). En equipos optimizados alcanza con ejecutar un script para lograrlo, compilando lo que se requiera, actualizando estructura e información en la base de datos, modificando variables de ambiente y logrando el entregable (un EXE, quemar un CD, implementar una Web o lo que sea).

    Si el proceso requiere más de un paso, entonces se tiene más probabilidad de cometer errores, y cuando la fecha de entrega se acerca existe una tendencia a arreglar “rápido”, en los últimos 5 minutos, ese último bug encontrado (en esos 5 minutos la probabilidad de error es alta).

    Dicho sea de paso, si se utiliza SVN como herramienta de control de versiones, no es descabellado pensar en desarrollar un Hook que ante la aplicación de un Tag predeterminado, o la existencia de cierto texto en la descripción del último cambio, dispare automáticamente el proceso de implementación. De esta forma la cantidad de pasos necesarios para realizar la implementación es cero!

  5. Cada programador actualiza diariamente su versión local de desarrollo?
  6. Esto está combinado con los dos puntos anteriores. Si se usa control de versiones y las implementaciones están automatizadas, puede generarse un mecanismo que fuerce la implementación diaria en un entorno de desarrollo. El proceso deberá asegurar que la aplicación siga compilando/funcionando adecuadamente, y de esta forma gran parte de los errores que puedan cometerse en el desarrollo no demoran más de 1 día en ser detectados.

    Si esto funcionó bien, lo primero que deben hacer los programadores al día siguiente es actualizar su copia local. Si el build falló, entonces mientras se arregla cada desarrollador puede seguir trabajando con su copia del día anterior.

    Joel cuenta que en el equipo de desarrollo de Excel, del cual formó parte, tenían como regla que aquel programador que rompía el código, como “castigo” era el responsable de verificar el resultado del build diario, hasta que otro programador rompiera el código nuevamente. Esta es una buena idea para estimular a los desarrolladores a no generar errores en el repositorio de control de versiones, y por el otro lado hace que vayan rotando así todos en algún momento monitorean el proceso de build diario y de paso aprenden cómo funciona.

  7. Tenés una herramienta para registrar y administrar los bugs?
  8. No importa lo que uno intente hacer para evitarlo. Toda aplicación tiene bugs. Una organización que funciona bien, registra estos bugs, los categoriza, los asigna y eventualmente los resuelve. Es muy difícil lograr esto sin una herramienta adecuada que registre todos los bugs conocidos. Es inútil utilizar otro método. Nadie puede recordar una lista de bugs de memoria, y el uso de mails interminables no da resultado. Si no hay más remedio, debe utilizarse una planilla de cálculo con al menos los siguientes datos:

    – Número de bug
    – Fecha de creación
    – Título
    – Descripción
    – Pasos necesarios para reproducir el error
    – Persona asignada
    – Estado (pendiente, asignado, en curso, cerrado, etc.)
    – Fechas de seguimiento, como ser fechas de alta, asignación, testing, de implementación…

    Si realmente está dispuesto a organizarse como corresponde, entonces debe evaluar la implementación de alguna de las herramientas disponibles. En otro post hablaré de este tema, pero por el momento quisiera al menos mencionar que luego de haber evaluado y utilizado muchas alternativas, para la mayoría de los casos sugiero JIRA.

  9. Aprovechás todas sus oportunidades para arreglar los bugs existentes al escribir código nuevo?
  10. Esto es bastante simple de entender. Cada vez que se empieza a trabajar en una funcionalidad de un sistema, debería evaluarse si “de paso” es posible solucionar alguno de los bugs registrados a bajo costo. También es cierto que cuanto más pronto se arregle un bug nuevo, el desarrollador tendrá más fresco el conocimiento sobre el código a reparar (si transcurre 1 año existe un costo inicial de análisis que debe agregarse al tiempo de desarrollo en sí mismo).

    Lograr este punto requiere método, disciplina, tener una buena herramienta de gestión de bugs, diseñarla de modo tal que sea simple asignar un bug a un módulo/funcionalidad/programa… y tener constancia y orden en la ejecución de los proyectos.

    Si se está desarrollando sobre un producto estable y evolucionado, otra filosofía que puede adoptarse es la de cero bugs. Esto implica que antes de realizar un desarrollo nuevo, debemos asegurarnos de que todos los bugs existentes y registrados de la versión anterior han sido resueltos.

  11. Contás con un cronograma de trabajo actualizado?
  12. Este es un punto complicado de lograr. Muchos programadores mencionan que una de las cosas que menos les gusta es tener que estimar tiempos de desarrollo. La respuesta puede ser algo del tipo “Estará terminado cuando lo termine”. Lamentablemente esto no es suficiente. Existen generalmente muchas decisiones de negocios que estarán basadas en el timing del desarrollo. Incluso la asignación de prioridades solo es efectiva cuando se conoce el tiempo requerido para encarar los proyectos pendientes.

    La mejor forma de trabajar ordenadamente es contar con cronogramas de trabajo actualizados. Para ello los líderes de proyectos deberán destinar una buena parte de su tiempo a planificar y a actualizar los planes de proyectos en curso. Esta segunda parte es la que he visto fallar más frecuentemente. Microsoft Project es la herramienta (Project Server es muy bueno si somos más ambiciosos). Un Excel es mejor que nada.

  13. Escribís especificaciones antes de desarrollar cualquier funcionalidad?
  14. Escribir especificaciones es como usar hilo dental. Todo el mundo sabe que usarlo es bueno, pero nadie lo hace. Lo único que la mayoría de los programadores odian más que planificar, es escribir especificaciones. Como consecuencia muchos prefieren ir directo a modificar el código sin asegurarse que se ha comprendido bien el alcance del cambio a realizar.

    Si se escriben especificaciones, se descubren problemas antes de empezar a programar. Es más simple y económico resolver las dudas en esa instancia que cuando ya hay cambios a medio hacer en el código. El costo no es solo económico, sino también emocional. A ningún programador le gusta que el fruto de sus horas de trabajo deba ser desechado porque no estaba claro el alcance del proyecto y lo que se necesitaba era otra cosa.

    El software que se escribe sin basarse en un documento de especificaciones, tiene mayor probabilidad a tener problemas de diseño y de alcance.

    Hay dos soluciones a este tema. O se manda a los programadores a algún curso que los ayude a escribir (incluso a un taller literario, fuera de broma) o se contrata a project managers que se encarguen de esto. En cualquier de los casos, no se debe empezar a programar sin especificaciones.

  15. Los programadores tienen un ambiente de trabajo adecuado?
  16. Para lograr llegar al estado mental de altísima concentración en el cual los programadores son más productivos, podemos suponer que es necesario que transcurran al menos unos 15 minutos sin interrupción. Cuando se llega a ese estado mental, el programador pierde registro del paso del tiempo y produce cosas magníficas. Las distracciones tienen un costo importante (volverán a ser necesarios otros 15 minutos) y la probabilidad de cometer errores será mayor.

    Tomemos el siguiente ejemplo: Digamos que si interrumpimos a un programador aunque sea por un minuto, en realidad le hacemos perder 15 minutos de productividad. Para este ejemplo pongamos a dos programadores, Felipe y Miguelito, en un escritorio compartido. Miguelito no puede recordar el nombre de la versión Unicode de la función strcpy. Puede buscarlo en la web, lo que le llevaría 30 segundos, o puede preguntarle a Felipe, lo que sólo le lleva 15 segundos. Como lo tiene sentado a su lado, le pregunta, y Felipe se distrae perdiendo 15 minutos de productividad (para salvar 15 segundos de Miguelito).

    Ahora mudémoslos a oficinas separadas. Como Miguelito no puede recordar el nombre de esa función, puede buscarla en la web, lo que le seguiría llevando 30 segundos, o puede preguntarle a Felipe, cosa que ahora le lleva 45 segundos dado que debe pararse e ir hasta su oficina (cosa nada simple dado el bajo nivel de deporte realizado por Miguelito). Entonces, busca el nombre de la función en la web. En este caso Miguelito pierde 30 segundos de productividad, pero se salvan 15 minutos de Felipe. Genial!!!

  17. Usás las mejores herramientas de desarrollo que el dinero puede comprar?
  18. Las computadoras usadas por los programadores deben ser rápidas, contar con todas las herramientas necesarias, un excelente monitor (o dos si es posible). Cada vez que la computadora empieza a andar lenta, corremos el riesgo de que el programador se aburra y empiece a leer el diario, a conversar con el compañero sobre el último partido de fútbol, a pensar en lo lindo que sería participar del torneo mundial de Poker, etc. Además deben tener acceso a sus recursos necesarios de desarrollo. La función de los administradores es hacer todo lo posible para que los programadores se encuentren cómodos desarrollando. Ellos son, al menos en empresas destinadas al software, la parte más importante de la organización.

    Las empresas de primera línea no torturan a sus programadores. Incluso frustraciones insignificantes causadas por usar máquinas lentas o herramientas inadecuadas, hacen que los programadores se pongan gruñones y quejosos. Un programador gruñón y quejoso es un programador poco productivo.

    Finalmente, los mejores programadores pueden ser tentados fácilmente por otras empresas, simplemente ofreciéndoles equipamiento y herramientas de última generación… y nadie quiere perder a sus mejores programadores.

  19. Tenés un equipo de testers independiente del equipo de desarrollo?
  20. Si la organización no tiene, digamos, un tester por cada tres o cuatro desarrolladores, entonces o está generando un producto lleno de errores o está haciendo que los programadores realicen las pruebas. En promedio los programadores cobran más caro que los testers, con lo cual si ese es el caso se está desperdiciando dinero.

    Incluso dejando de lado el tema económico, el programador suele testear la aplicación desarrollada siguiendo el mismo razonamiento utilizado para programarlo. Inconscientemente no desea encontrar errores en su código, y no lo prueba con esa intención en mente. Lo prueba para asegurarse que funciona, no para encontrar errores.

    Deben contratarse testers y debe asignarse a una persona ordenada para coordinarlos.

  21. Cuando se evalúan nuevos postulantes, les pedís que escriban código durante la entrevista?
  22. Contratarías a un mago sin pedirle que haga un truco de magia? Y a un músico sin que te muestre cómo toca su instrumento? Contratarías a un cheff sin probar la comida que prepara? No lo creo.

    Sin embargo diariamente montones de programadores son contratados sin que se les pida programar nada! Parece ser que se disfruta más charlar con ellos, preguntarles experiencias anteriores, hacerles completar tests de inteligencia, que ponerlos frente a una PC y pedirles que nos muestren cómo resuelven un problema práctico.

    Si este es el caso, sugiero que lo modifiquen. Hay que pedirles a los programadores entrevistados que arreglen un programa que no funciona, o que desarrollen algo similar a lo que harán cuando trabajen en la empresa. Dales acceso aIinternet y a toda la documentación que requieran. Nadie debería elegir programadores por su capacidad para recordar sintaxis de memoria. No los tortures haciéndolos escribir pseudo-código a mano; recordá que no les gusta escribir en papel.

    (Comento algunas cosas más sobre la forma de entrevistar a un programador en este artículo).

  23. Realizás tests de usabilidad?
  24. El mejor test de usabilidad es el que se logra cuando se le pide a la primera persona que se cruza en el pasillo que pruebe el programa que se acaba de escribir. Si se hace esto con 5 personas, se logrará conocer el 90% de los problemas de usabilidad de la aplicación.

    Diseñar buenas interfases no es algo complicado de hacer, pero no todas las personas poseen la sensibilidad estética y la capacidad de ponerse en lugar del usuario para lograrlo. Hay formas de mejorar en esto, pero por lo pronto se puede empezar pidiéndole a conocidos que prueben la aplicación y nos comenten sus dudas.

Para ir terminando: Cuatro posibles usos para el Test

  1. Calificá a tu organización y contame cómo te fue.
  2. Si sos el gerente de un equipo de desarrollo, usá este checklist para ver si tu equipo está trabajando lo mejor posible. Cuando logres que tus programadores trabajen con calificación de 12, podrás dejarlos solos y dedicarte simplemente a hacer que los usuarios y otros gerentes no los molesten.
  3. Si estás buscando trabajo como programador, pedile a tu posible empleador que se autocalifique en estos puntos. Si el resultado es muy bajo, asegurate que entrarías con la autoridad suficiente como para arreglar estas cosas. Si no, finalmente te vas a frustrar y serás poco productivo.
  4. Si sos un inversor haciendo un due dilligence para juzgar el valor de un equipo de desarrollo, o si tu empresa de desarrollo está considerando unirse a otra, este test puede ofrecer una primera evaluación rápida.

Espero que les resulte de utilidad.

7 pensamientos en “12 pasos para programar mejor

  1. Nico

    Ojo con el “nominalismo” (lo acabo de inventar). Sería hacer todo eso pero sólo “nominalmente”. Pasa cuando una serie de técnicas se vuelve tan popular que todos saben que hay que tenerlas. Entonces todas esas medidas se vuelven en puntos de un checklist, de una burocracia. O para decirlo de otra manera: se puede hacer todo eso e igual trabajar mal. Para cada uno de esos puntos me imagino una respuesta positiva que sin embargo no ayuda a la empresa. Al final nada reemplaza al sentido común y al contacto con la realidad (pero como complemento estos son buenos principios).

    Saludos! =)

  2. dsalama

    Gracias Nico por el comentario. Como vos decís, nada reemplaza al sentido común y al contacto con la realidad.
    De todas formas, si una organización está muy lejos de cumplir con estas recomendaciones, en general lo tomaría como una mala señal…
    Esto no implica que cumplir con los 12 puntos garantice que se están haciendo las cosas bien, pero es un buen comienzo :-)
    Pensando en tu opinión, agregaría un paso 13: Verificar que cada dos o tres meses, la organización vuelve a cuestionar sus procesos y métodos en búsuqeda de seguir mejorando.

  3. Julio

    Dsalama

    Eso se llama mejora continua, si es un poco complicado cumplir con las metodologías pero si se aplican y se toman las mejores practicas que son de utilidad en tu empresa, veras que si hay resultados positivos para tenerlas

  4. Cr¡sT¡@no

    diego, su blog es estupendo. estoy analizando muchas de sus ideas para implementarlas en la empresa donde trabajo.gracias x su trabajo

Deja un comentario