Java et productivité des développements

Une fois n’est pas coutume, je commence par une précaution oratoire : je me place ici sans ambages dans la position de l’agitateur d’idées et prend le risque de n’être pas politiquement correct (d’un point de vue IT s’entend).

En 1990 Java a été inventé pour adresser le problème de la portabilité des applications, problème à l’époque très important puisqu’il réduisait d’une part les opportunités pour les éditeurs, d’autre part la liberté de manoeuvre pour les directions IT.

En 1993, lors de l’émergence du Word Wide Web, Sun a très vite saisi l’opportunité de profiler son langage comme la solution pour développer des applications Web.
Ce lui fût d’autant plus facile que la plupart des autres acteurs n’ont pas été attentifs à la révolution en train de se préparer dans le monde IT. Difficile à comprendre avec le recul, mais pourtant vrai. Rappelez-vous : même Microsoft a réagi sur le tard.

Avant l’apparition de Java, la majorité des efforts des éditeurs des outils de développement portaient sur l’amélioration de la productivité.

Et puis, retour en arrière. Fin des années 90, début des années 2000, on peut affirmer, sans peur de se tromper, que Java nous a ramené, de ce point de vue, au moins 10 ans en arrière. Avec en plus le fait que la productivité n’a finalement jamais été le driver principal dans l’évolution du langage.

Nous sommes aujourd’hui en 2012 et, personnellement en tous cas, j’estime que la productivité des développements Java reste en retrait par rapport à celle du client-serveur d’il y a vingt ans. J’en conviens, le propos est provocateur. Chacun le nuancera donc en fonction de sa propre expérience.

Les réticences autour du modèle J2EE, l’introduction (souvent un peu anarchique) de nombreux frameworks, a démontré le problème de la productivité dans le monde Java. Il faut d’ailleurs ajouté que l’intégration de ces frameworks (compliquée par la gestion des versions) est elle-même source de pertes de productivité (1). Sans parler des difficultés en matière de déploiement. Bref, il y a de quoi être effrayé par l’importance des différents efforts de support nécessaires autour du développeur proprement dit. Si la licence est gratuite, tout pris en compte, l’heure de vol en Java coûte quand même fort cher.

La volonté de rationaliser autour d’un seul langage, couplée à la volonté de réutilisation, a conduit à voir Java s’imposer pour tous les développements : applications publiques Web, applications de gestion internes interactives, et enfin batch.

Résultat : pour tous les types d’application, la productivité est aujourd’hui devenue sujette à interrogation, en tous les cas en regard des standards antérieurs.

A cela s’ajoute encore le fait que la technicité de Java a souvent conduit à scinder les fonctions d’analyse (2) et de développement. La disparition du rôle de l’analyste / programmeur a aussi contribué à dégrader la productivité.

C’est particulièrement vrai pour le développement des applications de gestion interactive de types CRUD. Sachant que nombre d’organisations sont confrontées à la question du renouvellement ou de l’abandon de leur mainframe, et donc , en partie au moins, au renouvellement de leurs applications CRUD, le sujet est important.

Une migration mainframe peut se faire selon différents scénarios, dont celui de la réécriture, le plus adéquat s’il s’agit de profiter de l’opportunité pour réduire une dette technique devenue trop importante.
Ce scénario demande impérativement de s’inquiéter de la productivité des équipes concernées, pour des raisons évidentes de gestion des coûts et des délais, et donc entre autres de celle des outils.

Je me pose dès lors la question suivante : les approches de type 4GL ou 5GL ne doivent-elles pas faire l’objet d’une réévaluation pour le (re)développement des applications de gestion interactives?
Après tout des outils tels que Windev (malheureusement fort limité à l’Hexagone) , Unipaas ou Caché sont utilisés avec succès. Sans parler, cas bien plus intéressant encore, des outils réservés au case management et à la gestion des processus métier.
Il va de soi que ces outils seront d’autant plus apprécié que le run-time délivré sera en Java, pour des raisons évidentes de portabilité et de succès du langage.

On peut déjà pronostiquer, s’il est lancé, que le débat avec les javaïstes sera difficile.

Si la recherche d’importants gains de productivité et une satisfaction plus rapide des demandes métier sont des préoccupations majeures de l’organisation, il me semble en tous les cas que ce débat mérite d’avoir lieu.

Bien entendu sans tirer de conclusions hâtives dans un sens ou dans l’autre.

Encore quelques mots pour terminer : la standardisation autour de Java est sans doute tirée par le “problème démographique” dans l’IT- les ressources étant trop peu nombreuses il n’est finalement de l’intérêt de personne de voir se multiplier les langages.
________________________
(1) Et de conséquences sur la performance !
(2) Je parle ici des application analysts, pas des business analysts qui interviennnent plus en amont.