Oui bien vu, un Architecture Owner a toute sa place. Je ne connaissais pas ce rôle, sans doute parce qu'il n’apparaît ni dans le guide officiel de Scrum (http://www.scrum.org/storage/scrumguides/Scrum_Guide.pdf) ni dans la définition des rôles de Scrum Alliance (http://www.scrumalliance.org/pages/scrum_101). En fait dans ce guide on cherche déjà en vain le mot "software", inutile d'y chercher "Architect". Mais c'est peut-être en train de changer sous l'impulsion de Ken Schwaber, qui pousse les sujets techniques à apparaitre dans Scrum. Ce qui lui a valu d'être éjecté de Scrum Alliance. L'histoire du schisme et les motivations de Ken sont intéressantes à lire : http://www.scrum.org/originsofscrumorg/. C'est à lui qu'on doit l'introduction d'une formation au développement logiciel en mode Scrum http://www.scrum.org/professionalscrumdeveloper/. Peut-être un Scrum 2.0, ou au moins un Scrum orienté software...

On peut entre autres choses en déduire qu'en France en 2007 il y avait peu de développeurs qui consultaient Google pour leur job de tous les jours.

Quand on fait des hacks CSS/HTML, qu'on utilise des commentaires IE ou qu'on travaille à faire en sorte que le même HTML soit bien rendu sur tous les navigateurs, fondamentalement on ne prend pas parti pour un navigateur, non ? Qu'on ajoute des hacks ou pas, c'est le même HTML qui est servi au navigateur (et comme tu le dis, le mieux c'est d'avoir le moins de code spécifique possible, c'est moins de travail de maintenance). En revanche si l'usage d'une balise qui indique à qui se destine le HTML se développe, on s'éloigne radicalement de cette voie "apolitique", on prend parti. Pour moi le X-UA-Compatible qui spécifie Chrome ou IE est le premier pas dans cette direction. Science-fiction : on peut imaginer que les PC soient livrés avec les trois ou quatre grands navigateurs du marché et leur système de "frame-switching" à la Google Chrome Frame. On en aurait la vie (de développeur) bien simplifiée. Plus besoin de s'arracher les cheveux pour rendre notre HTML cross-browser, il nous suffirait de spécifier le navigateur de destination... Cool. Mais la divergence des HTML serait engagée, avec des conséquences difficiles à évaluer. C'est pas pour demain, certes, mais ça peut aller très vite. D'autant plus vite que, comme tu le notes, les éditeurs on déjà tendance à développer leurs propres particularités dès qu'une nouvelle techno apparait.

C'est vrai que c'est un super service pour les gros sites. Mais à chaque fois qu'un développeurs Web s'amourache de Google AppEngine durant son passe-temps du dimanche, c'est un développeur .Net en moins et un prescripteur GAE de plus au boulot. Il y a gros à perdre pour MS : les développeurs puis les entreprises. Je ne comprendrai pas qu'ils ne réagissent pas.

Oui je suis entièrement d'accord, la fréquence ne fait pas tout, mais elle fait beaucoup.

Oui et aussi : + le deal Yahoo Microsoft autour de Bing. Loin du code mais proche du nouveau nerf de la guerre du soft : la pub.

db4o est en pointillé dans la dernière question "le Cloud va-t-il réussir là où les bases de données orientées objets ont échoué ?" . Peut-être y a-t-il des plans en vue pour adapter db4o au cloud ? Pour Alt.Net, les réunions sont loin de Rambouillet mais elle me manquent. Un peu de repos et j'y retourne avec plaisir mais avec modération pour faire dans la durée. Bandes de parisiens va !

En réalité, la part des applications dont le traffic justifierait une database non relationnelle me parait tout petit. Ce ne va probablement pas empêcher les DB NoSQL de pertuber l'équilibre actuel en vertu de l'effet "silver bullet".

En faveur des langages typés pour des projets d'envergure, il faut aussi considérer l'investissement considérable - et réussi - de Google dans Google Web Toolkit.

La dépendance du remaniement vis-à-vis de la nature typée/dynamique du langage considéré est une idée qui m'est soufflée par les grosses différences de "styles" de code que j'ai pu constater entre C++, C#/Java et Javascript, styles qui me semblent directement dépendant des outils. En C++ où les classes et les méthodes sont à écrire deux fois (.h/.cpp en l'absence d'outils de refactoring), les classes comme les méthodes me semblent plus grassouillettes qu'en Java et C#. En Javascript, je réfléchis à deux fois avant d'extraire une méthode ou de renommer une variable tant le risque d'amener des erreurs est grand en mode manuel (si un risque est non nul alors il est grand, corollaire de la loi de Murphy). C'est vrai les tests détecteront la régression s'ils sont complets, mais la différence avec les outils de refactoring Java/C# qui *garantissent* de laisser le code iso-fonctionnel est flagrante. Le remaniement n'est pas bloqué, il est plus ou moins freiné en fonction du courage du développeur. Ce qui prend 10 secondes en C#/Java coûte 3 minutes en javascript et amène des risques de régression : c'est un peu d'agilité perdue, sur la durée d'un projet ça compte beaucoup. J'aimerais bien avoir le temps de confirmer/infirmer l'effet de la disponibilité d'outils automatique de remaniement sur le style du code en analysant la taille des méthodes et des classes de différents langages sur un large corpus de code, par exemple à partir de code.google.com. Si quelqu'un se sent motivé...

Mais est-ce vraiment une philosophie du french SUG ou juste une méconnaissance d'XP ? Ou juste une maladresse : après tout il n'est pas dit dans ces questions qu'XP ne propose pas de pratique de gestion de projet. Les questions qui se rapportent à ces pratiques sont juste absentes... Tant pis pour ma Wii ;)