Sasume :

Il commence par comparer le design planifié et le design évolutif.
Design planifié = on décide du désign à l'avance et ensuite on code
Design évolutif = on code, et au fur et à mesure le design apparaît de lui-même

Selon lui, dans un monde idéal ou tu as des designers qui pensent à tout et des clients qui ne changent pas d'avis au cours d'un projet, le design planifié est une très bonne chose. L'inconvénient, c'est que si les besoins changent en cours de route, il est énormément difficile de tout changer avec un mauvais design au départ.

De l'autre côté, il y a le design évolutif, qui a en général tendance à être le vrai bordel, avec le problème que plus le projet grossit, plus c'est dur à débugger et plus ça devient chaotique.

Cependant, selon lui XP (extreme programming, une méthode de développement agile pas mal à la mode ces dernières années) rend le design évolutif plausible, rentable et même intéressant. Pour plus de détails sur XP : http://en.wikipedia.org/wiki/Extreme_Programming

Par exemple, XP est basée sur deux philosophies : toujours viser un code le plus simple possible, et ne rien implémenter à l'avance pour une fonctionnalité dont on aura plus tard. En combinant également ça à des tests permanents, beaucoup de prototypage et tout un tas d'autres trucs, ça semble marcher.

Il ajoute cependant des idées un peu moins conventionnellement rattachées à XP : par exemple qu'utiliser, même avec XP, des design patterns peut être utile, ainsi qu'une documentation UML minimaliste, voire de réfléchir à certaines choses concernant design à l'avance (surtout quand ne pas le faire pose de gros risques pour plus tard). Donc, son interprétation d'XP, c'est surtout que, même si tu peux (et dois) faire du design, tu ne le considères surtout pas comme statique et n'hésites pas à tout changer si nécessaire Donc en gros il combine la *philosophie* d'XP avec des techniques plus traditionnelles (mais également celles d'XP)