Artículo: La Barrera de la Complejidad

[CoLSoN2]

Dan MacDonald ha escrito un artículo que todo desarrollador amateur debería leer. Breve pero interesante. La verdad es que nunca había pensado en lo que él describe, pero ciertamente tiene razón.

[senior wapo]

Interesante. Gracias por el link.

[Lex]

...

[Ryuchan]

Pues yo no estoy de acuerdo en varias cosas de las que dice.
Si que es verdad que la complejidad de un proyecto aumenta a medida que lo hace la funcionalidad que se añada, pero lo que el llama "barrera de complexidad" no es un valor fijo para un proyecto y un desarrollador dados. Un mismo proyecto se puede enfocar de muchas formas, variando asi la posicion de esa barrera tan extrañamente definida.
En mi opinion, para que la complejidad de un proyecto no sea tal que perdamos su control, el remedio no pasa por escribir poco codigo, como insinua en el articulo (aunque es obvio que si disponemos de la capa de tecnologia creada nuestro proyecto sera mas simple de desarrollar), sino por usar la metodologia apropiada.

El autor del articulo comenta que en los inicios del desarrollo el tiempo invertido se traduce en miles de caratcteristicas que aparecen a los ojos del desarrollador, con lo que su motivacion es muy alta al ver lo rapido que avanza.
Quizas sea justo ese momento el inicio de los problemas, y donde se esta empezando a delimitar la frontera de la complejidad.
A mi modo de ver, pretender obtener resultados visibles muy deprisa es contraproducente en el sentido que obliga a descuidar el diseño del software y a menospreciar detalles que mas adelante seran fundamentales. Se estan poniendo los cimientos de un sistema software que luego sera dificil de extender sin realizar cambios traumaticos, y del que no habra vuelta atras (si obtener pocos avances visuales desmotiva, imaginaos volver atras, perder funcionalidad y tener que reescribir componentes enteros del sistema), con lo que la susodicha barrera de la complejidad se acercara implacablemente.

Si por el contrario, desde el inicio, el desarrollador se centra en el diseño del sistema, lo revisa con rigor y lo implementa cuidadosamente, puede encontrarse con que pasen muchos meses sin que vea un solo resultado en pantalla, pues los subsistemas basicos aun no estan listos para funcionar. En dicho caso, la barrera de la complejidad se puede convertir en la barrera del tedio y aparecer mucho mas pronto en el proceso de desarrollo.

La solucion buena, a mi modo de ver, es, como todo en la informatica, un compromiso. Un compromiso entre cuanto estas dispuesto a esperar para ver resultados y cuanto codigo desechable emplearas para obtener vistas de la funcionalidad desarrollada hasta el momento. Lo que no esta permitido a mi modo de ver, son las chapuzas en el codigo con el objeto de acelerar el desarrollo. No esta permitido el codigo poco pulido, que este alli para quedarse, y que pueda comprometer el futuro del desarrollo.

Creo que la habilidad de manejar el proyecto de la forma mas optima solo se adquiere con la experiencia. Cuantos mas proyectos se desarrollen, mejores diseños de software se haran y mejores decisiones se tomaran a la hora de escoger el orden en que implementar los diferentes componentes y el numero de prototipos que se decida implementar sobre estos.

[Sante]

Doy fe de que la citada barrera existe. Un artículo muy bueno, por cierto.

Pero como dice Ryuchan, la solución no pasa por escribir menos cantidad de código, sino incrementar su calidad, aplicar metodologías apropiadas, hacer uso de patrones de software, desarrollarlo de forma modular, y que para añadir una nueva característica no haga falta tener que cambiar la mitad del código ya existente.

De hecho, en el proyecto en que estoy trabajando ahora me ha pasado varias veces de desear volver al pasado, y haber diseñado tal o cual sistema de forma diferente, lo cual me habría ahorrado incontables horas de cambiar tonterias aqui y alla para incluir una nueva caracteristica. Es el tipo de cosas que solo se aprende con la experiencia, y la capacidad de "ver" lo que te va a hacer falta en el futuro.

Vamos, que para aprender hay que darse primero unos cuantos cabezazos con la barrera esa :mrgreen:

Otro tema que menciona de pasada es el de los contenidos. Personalmente, y tras la experiencia con este proyecto, estoy convencido de que los problemas en producir contenidos es uno de los grandes "amateur killers", y una causa común del fracaso de muchos proyectos.

<publicidad>
de hecho, tengo un artículo sobre el tema en mi blog, por si os interesa :mrgreen:
</publicidad>

El caso es que en muchos proyectos se da la combinación mortal de tener un juego basado en contenidos, con mucha cantidad de contenidos de alta complejidad, sin pipelines y herramientas adecuadas, y con pocos grafistas para producirlos. Es una sentencia de muerte.

Y lo que es peor. En estos juegos normalmente se necesitan a varios grafistas, que no se suelen interesar a no ser que vean que el proyecto tiene futuro, y siendo un juego basado en contenidos es dificil demostrarlo sin tener... bueno, algún tipo de contenido. La pescadilla que se muerde la cola.

En fin, un problema bastante común que por lo que pienso no se le da la importancia que merece.

Un saludo!

[Mars Attacks]

Curiosamente, en gráficos también pasa. Recuerdo estar haciendo en Blast tan ricamente unas cuantas extrusiones para un escenario y, al retormarlo el día siguiente, ver tal enjambre de vértices que no había forma humana de meterles mano, ni siquiera para texturizar.

[seryu]

Me parece que el problema fundamental es un mal diseño o cambios radicales, no el añadir funcionalidad.

He tenido que meterle mano a codigo que estaba hecho a capon, y otras veces he tenido la suerte de contar con una cantidad de recursos para poder hacer una tarea, y es ahi cuando te das cuenta del problema real.

Un ejemplo tontorron. Si haces un juego en el que los enemigos siempre tendran 1 esbirro, y luego decides que habrá enemigos con un ejercito bajo su mando, te daras de bruces con tu diseño y te tocara hacer una clase de comandantes.

Si hubieras hecho que cualquier enemigo pueda tener N número de enemigos subordinados, podrias haberlo cambiado sin problemas.

Hoy día, con la potencia de los ordenadores y la complejidad del codigo, mas vale programar pensando en la versatilidad y tender a casos generico. Para casos especificos, es mejor tirar de scripts o ficheros de configuracion, cuanto mas facilidad en la edicion, mejor.