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.
Merci pour cet input.
“- il n’y a pas eu d’architecte ou très peu dans ces projets et il n’y a pas de ‘separation of concern’ entre les couches d’architecture (codage dans le click() ou …”
Probablement un des plus grands dangers du client serveur (un de ceux qui m’ont conduit à défendre la mise en place de la fonction architecte – il y a en a bien d’autres ;-)).
Je profite de cette réponse pour appuyer sur le fait que mon “interpellation” ne vise pas à remettre Java en cause, mais à poser la question des moyens complémentaires au langage, qui peuvent être souhaitables pour améliorer le respect des délais de livraison, que ce soit dans la phase de développement initiale ou plus tard dans la phase de maintenance.
Et en n’oubliant pas le “cauchemar ” des déploiements.
De mon point de vue l’argument, “le développement ne représente qu’une petite partie du TCO”, peu contestable, occulte trop systématiquement la problématique du “time to market”.
Bonjour, me voici le premier à faire un commentaire.
La société pour laquelle je travaille est un éditeur de logiciel qui propose des produits pour:
– l’industrialisation des développements Java et .Net
– la modernisation automatisée d’application anciennes (Cobol, Cient Serveur, web) vers Java et .Net.
Pour ma part j’ai commencé ma carrière sur client serveur (Powerbuilder, Oracle Forms) puis j’ai migré vers Java et Java JEE.
Mainenant que mon rôle consiste à moderniser des patrimoines anciens je peux vous assurer qu’une application ayant vécu plus de 15 ans est toujours dans un etat de fraicheur limité quelque soit son language de programmation d’origine (cobol, java, client serveur).
La différence de productivité n’est pas le véritable coût de possession des applications, le véritable coût provient de la dégradation progressive du pzatrimoine logiciel.
Celui ci provient toujours des facteurs suivants:
– developper en ayant mal conçu: pas de phase de conception donc plus rapide, mal conçu mais rapidmeent fait, pas de documentation
– budget limité: a défaut d’avoir le budget pour bien construire j’ajuste sur le coût des matériaux (qualité des ressources humaines par exemple)
– 50% des projets échoue il ne sert à rien de faire de la qualité, faisons vite
Dans le cadre de Java un élément est venu se greffer en plus, il s’agit de la très/trop grande variété de framework concurents qui font les mêmes choses. La variation des standards est par nature l’opposé de l’industrialisation. Or être productif n’a de sens par pour soi même mais pour le développeur qui passe après.
Il faut donc maitriser une approche industrielle et se servir de ce standard pour approter de la productivité.
Le client serveur force cette démarche car elle défini le cadre de travail: l’IDE et les APIs propriétaires de l’outil. Donc cette partie la est stable et apporte productivite.
Cependant l’histoire nous prouve, et je le vis au quotidien quand nos clients nous demande de réécrire telle ou telle application client serveur, que ce bénéfice a été mal exploité malheureusement.
En effet l’architecture étant imposée et “facile” d’accès, il s’est passé les choses suivantes:
– puisque c’est facile je peux mettre des ressource de profil plus aisé à recruter et moins cher => le code n’est pas structuré et difficile à maintenir
– il n’y a pas eu d’architecte ou très peu dans ces projets et il n’y a pas de ‘separation of concern’ entre les couches d’architecture (codage dans le click() ou lien de la mise en plance d’event handler centraux et de gestion d’évènement)
– l’IDE fait tout, je n’ai pas besoin de documentation
Dans le développement, comme dans tout autre domaine industriel il faut raisonner sur la durée de vie du produit manufacturé:
– cout de mise en place des outils de fabrication et de formation des ingénieurs
– cout de fabrication
– cout de maintenance sur la durée de vie (20 ans minimum) incluent les changement technologiques tels que les montées de versiob Powerbuilder ou Java et le besoin de formation constante
– cout de démentellement
Les deux première étapes ne représentent même pas 10% du cout global (etude gartner), il s’agit donc de gagner sur la durée et pas au décollage.
Dans notre approche nous avons donc créé un outil qui compile la modélisation d’un logiciel pour le générer intègralement sans dépendre de la cible d’architecture, et faisons l’inverse pour réécrir des système anciens.
10 années d’expérience nous ammènent à constater une amélioration mias cela reste un outil. Il faut quand même maitnenir le niveau de compétence nécessaire et justifier les budgets qui vont avec.