Nil (./83) :
Ca ne peut pas marcher en équipe

Si, il y a bien moyen de coder de manière purement incrémentelle en équipe, du moins dans beaucoup de cas. Évidemment, si l'équipe n'a pas l'habitude de travailler ensemble, si tous les développeurs codent en même temps, si le projet n'a pas une décomposition en modules évidente dès le départ (ou si l'interaction entre les modules est trop forte) et si les outils utilisés pour coder ne permettent pas de merges efficaces, ça va être le désastre. Mais il y a plusieurs moyens de s'en sortir. Par exemple développer en paire avec une personne qui code le jour et une la nuit (déjà essayé, par exemple sur ld-tigcc (même si ce n'était pas forcément un projet "conçu en codant" et même si Sebastian l'avait commencé seul, donc ce n'est pas forcément un bon exemple): d'habitude, Sebastian codait le jour et moi la nuit et on s'échangeait les patches par mail, il n'y avait presque pas de conflits entre les patches parce que chacun travaillait à son tour).

ça ne peut pas marcher quand tu travailles sur un projet commandé (pour lequel tu as un cahier des charges)

Si. On implémente une charge à la fois de manière incrémentelle et à la fin du processus, on a couvert tout le cahier des charges. Le cahier des charges est censé spécifier les exigences à couvrir, pas la manière dont on le fait, donc on peut très bien coder avec un cahier des charges, mais sans un concept de l'architecture du programme.

Bien sûr il y a aussi le cas où la liste des charges est dynamique (d'ailleurs, c'est souvent le cas en pratique même quand sur papier, il y a un cahier de charges; il est tout aussi difficile pour le client que pour le programmeur de prévoir le futur), dans lequel cette liste évoluera aussi au fur et à mesure qu'on code, mais même quand la liste est fixe, ça ne change pas de beaucoup cette manière de coder. (Cela dit, connaître les exigences à l'avance, quand la liste est vraiment fiable, peut faciliter des méthodes de programmation où on planifie à l'avance. Quand les charges exactes ne sont pas connues dès le départ, c'est tout de suite beaucoup plus difficile.)

ça marche difficilement pour un projet sur plusieurs années...

Pourtant il y a plusieurs de mes projets codés comme ça qui ont plusieurs années, et j'arrive toujours à les maintenir. (Il y a un seul projet que je n'arrive plus à maintenir, c'est Tokens89: un bordel infame de bidouillages fragiles parce que je n'y connaissais rien au parsing à l'époque, du code qui dépend d'à peu près toutes les propriétés tordues du VB5 (langage propriétaire et obsolète), bref faudrait tout réécrire. Ce n'est pas du tout un problème d'organisation du code.)