fplanque: Techno

L'éclatement de la bulle Internet et des NTIC en général aura définitivement fait passer le développement informatique dans l'ère industrielle.


Les temps sont durs pour les développeurs isolés au fond de leurs garages... même pour les petites SSII aux méthodes quasi-artisanales. Non pas que les grosses SSII n'aient aucun problème, mais elles, elles survivront. Croyez moi, il n'y a rien de tel que de regarder comment ça se passe en province en ce moment pour être pris de compassion pour ces artisans de l'informatique du XXème siècle; eux qui se retrouvent coincés entre les gros projets qui nécessitent plus de méthode qu'ils ne peuvent en offrir, et les petits projets que les utilisateurs peuvent pratiquement réaliser entièremenet eux-même grâce à des outils de plus en plus intégrés.


Les plus malins d'entre eux auront sauté dans le train et créé leur propre outil; un outil qu'ils peuvent au moins vendre aux utilisateurs s'il ne peuvent le mettre en oeuvre sur mesure. Prochain écueil pour eux: la consolidation du secteur et à terme: l'intégration complète desdites fonctionnalités dans Windows! Inutile de résister, Microsoft a toujours fait comme ça! 8| Cela prendra quelques années, certes...


Au niveau du web, celà se traduit de plus en plus par l'abandon des technologies de mise en oeuvre rapide - je pense à PHP, ASP, ColdFusion... - au profit de frameworks largement plus complexes - j'ai nommé J2EE et .NET - pour les plus gros projets, et de sites préformattés (mais "customizables") pour les plus petits. La bande des "moyens projets", elle, semble de plus en plus étroite.


Exit donc les sites jetables réalisés sous l'impulsion des agences de com, renouvelés au rythme des campagnes publicitaires... de préférence deux fois par an! |-|


Sur le low-end, on assiste déjà à la banalisation ("commoditization") des solutions de commerce électronique. Avantage Microsoft pour ceux qui hébergent leur propre site. Avantage provider pour ceux qui externalisent.


Sur le high-end, le champ de bataille oppose J2EE à .NET . J2EE en réalité c'est à 80% IBM et non pas Sun comme on pourrait le croire. Alors IBM contre Microsoft... finalement peut être que rien n'a changé depuis 15 ans... :>>

Mon coeur de métier c'est la conception et le développement de systèmes d'information. Mais c'est quoi, au fait, un "système d'informations"?

Si vous aussi vous trouvez que c'est une notion un peu abstraite, voici la définition que je donne habituellement pour tenter de clarifier: ;)

On peut prendre comme point de départ un site web. Tout le monde connait les sites webs. Des sites tels que celui de la sncf, de la fnac, de météo france ou même celui des impôts... :roll:

En fait, ces sites web ne sont que la partie visible de l'iceberg. L'iceberg, ici, c'est le système d'information. Ce système reçoit et centralise des informations provenant de différentes sources. Il peut s'agir de références et caractéritiques de produits, d'horaires, de données météo, de commandes, de transactions financières ou plus généralement de textes, tableaux, images et même vidéos... (on peut alors parler de systèmes d'information multimédias).

Toutes ces informations, le système les traite, les transforme, les stocke puis les redistribue en fonction des besoins des utilisateurs et sur différents canaux...

Ces dernières années, les canaux privilégiés étaient le web et l'email.

Il y a une dizaine d'années c'était, le Minitel.

Dans les années à venir, les canaux privilégiés seront sans nul doute à destination des terminaux mobiles tels que téléphones portables et ordinateurs de poche. Le SMS est un exemple de technologie déjà largement utilisée dans ce domaine.

On peut également s'attendre à un développement de la télévision interactive grâce à l'ADSL.

Cela fait probablement une bonne décennie que les entreprises ne jurent plus que par la rentabilité maximale du mètre carré, créant ainsi des opens spaces à tout va.

Toutefois, c'est avec un certain bonheur que j'entends aujourd'hui quelques manifestations de retour à la raison: celle de la rentabilité maximale du salarié (:!:) lorsqu'on lui offre un environnement de travail plus confortable, ou du moins plus propice à la concentration ou à l'efficacité.

Voir par exemple le dossier de JDNet, ou au moins les principes de base.

Malheureusement, les initiatives de la conception de bureaux poussées à l'extrême telles que celle de Joel Spolsky risquent des rester des exceptions...

Ceci dit, une des principales motivations de la démarche de Joel est de se créer un avantage concurrentiel tangible afin de lui permettre de recruter la crême des développeurs. Je me demande qui osera transposer cette démarche à du personnel moins qualifié... :?:

Traditionnellement, on se disait que pour développer plus vite, il fallait soit faire travailler plus de développeurs, soit les faire travailler plus longtemps chaque jour.

Le problème avec plus longtemps chaque jour, c'est qu'il ne tiennent pas longtemps! :roll:

Le problème avec plus de développeurs, c'est que la collaboration devient de plus en plus complexe et la gestion de plus en plus importante. Il faut une répartition des tâches minutieuse, une modularité exemplaire et un système de gestion de code source à la hauteur.

Tout ça coute cher... très cher... souvent trop cher et il reste plus rentable, dans de nombreux cas, développer moins vite, avec moins de développeurs! :|

Une autre alternative consiste à décharger le développeur des tâches ingrates de manière à ce qu'il puisse se concentrer sur l'essentiel. Le développeur appréciera souvent de se faire livrer à déjeuner... et parfois même à diner (ne pas abuser du régime pizza, ça lasse et la lassitude nuit à la créativité)... Mais plus sérieusement, il appréciera que quelqu'un d'autre s'occupe de la documentation... et par dessus tout: ce dont le développeur moyen à horreur: c'est le testing! Il repoussera toujours les tests à plus tard alors qu'il serait en fait plus judicieux de tester tout au fur et à mesure des modifications, avant qu'on ait oublié ce qu'on a bien pu modifier exactement et qui puisse provoquer tel ou tel bug... (Je ne m'étends pas sur la nécessité de tester le plus rapidement possible, c'est une vérité communément avérée! :|)

Lire la suite »

Je n'ai jamais réussi à comprendre comment Extreme Programming pouvait être appliqué dans le monde réel... et je suis absolument ravi de constater que Cédric se pose la même question! 100% d'accord ;)


[Concernant le pair programming: ] J'en ai plusieurs fois fait l'expérience: mettre deux développeurs côte à côte devant le même écran, c'est le meilleur moyen de les énerver tous les deux pour la journée!