Desarrollador con calidad vale por dos (o más…)

Las metodologías ágiles nos recomiendan centrar nuestros esfuerzos en aportar valor al cliente. Dicho valor se traslada a través de los entregables que el equipo va liberando en las diferentes iteraciones. En el mundo del desarrollo de aplicaciones informáticas, el más importante de todos los artefactos que entregamos es el Software. Y este software se genera desde el código que generan los miembros del equipo.

Bueno eso este claro. Y que menos se puede pedir al equipo que se aplique al máximo con el código que genera? Como desarrollador de software el código es tu producto final, y este debe ser desarrollado con la máxima calidad que nos sea posible.

Algo que todos (los que entendemos como funciona el negocio del desarrollo de software..) tenemos claro, es que es más rentable asegurar al calidad de nuestros desarrollos desde las primeras etapas del proceso en vez de corregir los errores más tarde. El impacto de los errores crece exponencialmente cuanto más tarde se descubren.

Por lo tanto, como desarrolladores profesionales que somos, debemos poner especial hincapié en mantener presente la calidad en nuestros proyectos. Es fácil de decir, pero como a menudo, no tan fácil de conseguir…

Existen algunos grupos de problemas comunes que podemos identificar como focos problemáticos:

  1. Comunicación pobre y malas interpretaciones
    La capacidad de comunicación del ser humano es uno de los factores que le diferencia del resto de las especies. El grado de abstracción que podemos aplicar a la misma es muy alto. Esta característica, nos permite transmitir mucha información de manera muy efectiva.

    Por ejemplo, si yo te digo, singelton, grano fino, o capa de servicios y ambos tenemos un conocimiento equivalente en la materia, hemos conseguido transmitir una serie de conceptos más o menos complejos de manera optimizada.

    Es una herramienta potente, pero que debemos cuidar para evitar desviaciones igual de potentes. La comunicación debe ser clara y fluida, asegurando que el receptor ha comprendido el mensaje en la misma dimensión que deseamos emitirlo. No se debe escatimar en comunicación funcional, técnica, recabar feedback del equipo y aplicar un poco de psicología (la empatía puede ser la clave). Colaborar en este juego es parte de la tarea de cualquier miembro de un equipo.

  2. Errores de programación
    Las personas  escriben código y las personas comenten errores. Ergo…el código tiene errores (ahora no abusemos del mismo para hacer chapuzas diciendo es intrínseco el error en la persona…)

    Escribir buen código no es fácil. Debemos tener en cuenta aspectos como seguridad, rendimiento, localización, mantenibilidad… y en tiempo record!

    Aunque apoyarnos en el CLR ayuda, siempre existirán bugs que tendremos que corregir y realizar mantenimiento sobre el mismo. Y esto ocurre haciendo las cosas todo lo bien que podemos, esforzándonos al máximo como desarrolladores. Imagínate si no lo hacemos así…

  3. Falta de realimentación de pruebas
    Escribir pruebas unitarias es un trabajo que (casi) no aporta visibilidad. Lleva tiempo y no es código fácil de reutilizar. Aunque los desarrolladores sabemos que debemos escribirlas y esforzarnos y alcanzar la cobertura d código marcada por los parámetros de calidad del proyecto, a menudo nos enfrentamos a desincentivos que tientan a no realizarlas. Pero lo que es seguro, es que sin un buen conjunto de pruebas, (no tiene que ser muchas pero si bien diseñadas) es muy fácil cambiar código y no descubrir los efectos secundarios no deseados hasta demasiado tarde. (vamos creando un coladero…)
  4. Versión distorsionada
    Gracias a la metodología al principio, y a las herramientas de control de código fuente, más adelante no se han producido millones de asesinatos entre los desarrolladores. Aún así existen archivos y configuraciones de puestos que no son propios del código fuente cuyas diferencias producen errores que son difíciles de diagnosticar. Cuantas veces hemos oído eso de “En mi máquina funcionaba!”.
  5. Falta de transparencia
    Para desarrollar un proyecto con éxito hace falta todo. Como una de las piezas falle o no se comunique adecuadamente todo el proyecto se puede venir abajo como un castillo de naipes. Tradicionalmente, han sido mundos diferentes (e inconexos!!) aspectos como la infraestructura de desarrollo, el sistema de gestión del proyecto, el trazado de requisitos/errores, métricas…(Intenta sincronizar el s.v.n. con el Visio que se sacó tu gerente de la manga…;))
    En esta situación, el equipo tiene poca visibilidad respecto al estado global del proyecto. (aparte de los odiados y poco fiables informes de estado…)

Cada una de estas cinco categorías son un foco potencial de problemas que afectan directamente a la calidad del código realizado. Esto implica que el mecanismo que el cliente emplea para evaluar el valor aportado, tiene problemas que afectan, directamente, a las sensaciones que transmitimos. La aparición de herramientas que nos permiten gestionar todos los aspectos relacionados con el desarrollo de manera orquestada vienen a facilitarnos la vida, y conocer sus posibilidades es un esfuerzo con seguro retorno de inversión.

Por nosotros que no quede…

2 comentarios en “Desarrollador con calidad vale por dos (o más…)”

  1. De acuerdo contigo en todo. Lamentablemente los buenos desarroladores suelen “huir” en cuanto pueden a puestos “superiores” para ganar más pasta. A menudo, sobrepasando el límite de su capacidad (ya sabes, un excelente desarrollador pasa a ser un analista mediocre y luego un mal gestor).

    Pero es lo que hay, en un pais donde el desarrollador es visto como el último mono facilmente sustituible por cualquier otro, con sueldos miseros y jornadas maratonianas. Mientras esto siga asi, dificil va a ser conseguir proyectos de calidad. Lamentablemente los clientes que contratan los proyectos sólo se fijan en si el interfaz es bonito o no, y si aquello funciona más o menos bien.

  2. Me está gustando mucho lo que escribes. Ya tienes un fan!! 😉

    Yo añadiría: Falta de compromiso, creo que a veces a los desarrolladores nos cuesta estimar o ayudar en las estimaciones y es algo que está dentro de nuestras obligaciones (sin perder de vista que una estimación es una aproximación, no un contrato) y tratar de esforzarnos, en la medida de lo posible, por llegar a cumplir el compromiso. Creo que esto impacta diréctamente en la calidad, ya que es vital cumplir con las iteraciones y ofrecer visibilidad.

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *