D'un autre côté on est plus productif en dev aujourd'hui : langage de programmation sans fuites mémoires, outils de test automatique, intégration continue, plus de bibliothèques open source plus matures à réutiliser et enfin le retour d'expérience de deux autres moteurs web...
C'est vrai qu'on a plein d'outils aujourd'hui, mais "plus productif", je ne pense pas.
La complexité, la multitude de couches qui s'empilent les unes sur les autres autant côté front que back, les nombreuses pratiques/méthodologies (TDD, BDD, Agile, DevOps, ...) qui sont plus ou maîtrisées, les évolutions d'architecture, les aspects qui auparavant étaient minorés (sécurité, suivi des dépendances, avec les outils dédiés et tout le suivi que ça entraîne...). Tous ont des bénéfices évidents, notamment sur le long terme, mais à mon sens ont eu un impact négatif sur la productivité court/moyen terme.
Dans mon organisation, on est devenu incapable de délivrer une "version 1" qui ne prenne pas 3 fois le temps qu'aurait mis un dev Cobol dans les années 80. Et le Cobol n'est pas particulièrement sensible aux fuites mémoires...
[^] # Re: Barrière d'entrée très haute pour être compétitif
Posté par Dring . En réponse au lien Changement de gouvernance pour le navigateur indépendant Ladybird . Évalué à 3.
C'est vrai qu'on a plein d'outils aujourd'hui, mais "plus productif", je ne pense pas.
La complexité, la multitude de couches qui s'empilent les unes sur les autres autant côté front que back, les nombreuses pratiques/méthodologies (TDD, BDD, Agile, DevOps, ...) qui sont plus ou maîtrisées, les évolutions d'architecture, les aspects qui auparavant étaient minorés (sécurité, suivi des dépendances, avec les outils dédiés et tout le suivi que ça entraîne...). Tous ont des bénéfices évidents, notamment sur le long terme, mais à mon sens ont eu un impact négatif sur la productivité court/moyen terme.
Dans mon organisation, on est devenu incapable de délivrer une "version 1" qui ne prenne pas 3 fois le temps qu'aurait mis un dev Cobol dans les années 80. Et le Cobol n'est pas particulièrement sensible aux fuites mémoires...