Principios de la calidad del software de Watts Humphrey IV

Principio 2: Para obtener calidad de manera constante los desarrolladores deben gestionarla en su trabajo.

Debe formar, por tanto, parte del propio proceso de desarrollo y no ser considerada como una actividad que se realiza en momentos puntuales del mismo, independientemente de que ambos enfoques puedan ser complementarios e incluso recomendables.

Cuanto más próxima a su origen sea la detección y corrección de un problema menos coste supondrá. Más adelante, con más funcionalidades, con más código, con más deuda técnica todo se complica. Es cierto que el aumento de la complejidad no afecta a todo el código por igual, porque hay componentes más críticos que otros, pero en general sí que se puede afirmar que con el tiempo y la distancia los errores son más complejos de corregir.

Y no solo se trata de defectos, sino de decisiones sobre la arquitectura, modelo de datos o a nivel funcional que después orientan el desarrollo de una determinada forma, haciéndolo todo más difícil: desde el mantenimiento hasta la usabilidad y que pueden suponer, si se tarda demasiado tiempo en darle una solución, tener que tirar buena parte de la aplicación a la basura.

Si los desarrolladores no aplican buenas prácticas, que no solo están relacionadas con la programación o con la arquitectura, incluyendo la refactorizacion, sino también con el testing y con la verificación de las especificaciones funcionales independientemente de su naturaleza (requisitos, historias de usuario, etc…), no es posible alcanzar esos objetivos de calidad.

Y no es cuestión de que estén mejor o peor formados en este aspecto, que también influye, sino que el problema principal se encuentra en que no están comprometidos con este objetivo ya que su preocupación se centra en terminar las tareas que tienen asignadas, sin tener en cuenta que terminar no es que te compile la clase o que incluso te arranque la aplicación, sino que funcione y que sea mantenible (dentro de las posibilidades que se hayan tenido).

Los jefes y/o el cliente tienen mucha culpa de esto, cuando presionan a los desarrolladores con un alcance y unos plazos prácticamente imposibles y no solo en momentos puntuales sino de manera sostenida en el tiempo. Sin embargo, no es siempre la causa última que provoca ese comportamiento porque todos hemos podido comprobar que se siguen repitiendo determinadas malas prácticas en proyectos en los no que existen esas condiciones.

Anuncios

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s

A %d blogueros les gusta esto: