Brian Kernighan. La complejidad

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.

Anuncios
4 comentarios
  1. La complejidad no es el problema, el problema es la mala gestion de la misma, estamos tan obsesionados con los lenguajes y herramientas que no percibimos que lo que la diferencia entre un buen software y uno malo esta en la gestion de la complejidad del codigo.

    • jummp dijo:

      Es cierto, la complejidad del código tiene mucho que ver, pero también la complejidad de la solución funcional ya que condiciona bastante la complejidad del código.

  2. jj dijo:

    Yo si creo que si se debe tender a optar por soluciones simples que resuelvan el problema complejo aunque se deje funcionalidades para nuevas versiones. Cuando se plantea el sistema, se debe tener en cuenta el coste del mantenimiento de esos sistemas que por su envergadura y arquitectura requieren de muchos recursos que después no se disponen….

    • jummp dijo:

      Así es. Abordar el proyecto como máximos e intentar ir a por ese máximo desde el principio está demostrado que no suele dar demasiados buenos resultados salvo que se disponga de un presupuesto y de un tiempo tal que permita tomarnos esa licencia (aún así no lo aconsejaría, pero no es habitual encontrarnos con proyectos así.

      Soy de la opinión de que hay que dividir el sistema a desarrollar en partes y que el usuario las priorice y trabajar en función de esa priorización, de esta forma nos aseguramos (si el usuario ha priorizado bien) de que por lo menos tendremos la parte fundamental del sistema funcionando (si los desarrolladores han trabajado bien y el usuario ha dado bien sus especificaciones) y con recursos suficientes como a través del feedback realizar las mejoras que sean precisas.

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: