archivo

Archivo de la etiqueta: Brian Kernighan

Resulta complicado que no lleguen defectos a producción. Llegado a un punto, la inversión a realizar para tratar de que el número de defectos que lleguen a producción sea cero, crecerá exponencialmente, si bien, no se trata solo de echar dinero, sino de hacer las cosas bien, y mucho mejor si se hacen desde un principio y están integradas como una parte más del proceso de desarrollo.

Cuanto mayor sea la complejidad del sistema, cuanta más deuda técnica exista, más posibilidades hay de surjan defectos y de que estos resulten, en ocasiones, complicados de detectar, porque en muchos casos serán consecuencia de una combinación de actuaciones del usuario que no ha sido contempladas o testeadas previamente.

¿Cuántas veces se ha tenido un cuidado extremo en tratar de que no se cuelen defectos y después, cuando el producto ha entrado en producción, han empezado a aparecer errores?

Por ese motivo, considero importante que los responsables funcionales y determinados usuarios empiecen a testear el producto (independientemente de la estrategia de testing utilizada por el equipo de desarrollo) desde la misma etapa de construcción, desde el mismo sprint, conforme se van completando historias de usuario. De esta forma, no solo se consigue perfilar mejor determinados aspectos de las historias, sino que también se permiten detectar defectos que probablemente hubieran llegado a producción.

Sobre lo comentado en este artículo, me parece muy interesante la siguiente cita de Brian Kernighan: “Cada nuevo usuario en un nuevo sistema descubre una nueva clase de bug”.

Para Brian Kernighan el control de la complejidad es la esencia de la programación.

Complejidad supone más esfuerzo en la construcción y en el mantenimiento, más probabilidad de que existan errores y sistemas de información más complicados de utilizar para el usuario.

La complejidad es resistencia al progreso en el desarrollo y resistencia cuando se trata de adaptarnos al cambio.

La complejidad es agotadora para los desarrolladores y una carga que lleva el producto durante todo su ciclo de vida.

Es necesario hacer un esfuerzo en todas las etapas del proyecto, desde su concepción hasta su entrega con el objetivo de encontrar la solución más simple que satisfaga las expectativas del usuario (y que permita un mantenimiento lo más simple posible ajustado a las características del sistema).

Buscar lo más simple implicará entender bien los procesos de fondo que informatiza el sistema, pensar en el usuario, pensar en el software es susceptible de ser modificado en todo su ciclo de vida, pensar en que hay que ser prácticos (tanto desarrolladores como usuarios) y no llenar el producto de funcionalidades que no se utilizan o que van a tener un uso residual.