N'y a-t-il pas vraiment eu une chose au cours des 20 dernières années qui a fourni d'énormes gains en développement de logiciels? [fermé]

Dans No Silver Bullet , Fred Brooks formule diverses prévisions sur l’avenir du génie logiciel, qui se résument de la manière suivante:

Il n’existe pas de développement unique, que ce soit en technologie ou en technique de gestion, qui, en soi, promet une amélioration même d’ un ordre de grandeur de la productivité, de la fiabilité, de la simplicité.

Son argument est très convaincant. Brooks écrivait en 1986: avait-il raison? Les développeurs de 2014 produisent-ils des logiciels moins de 10 fois plus vite que leurs homologues de 1986? Selon une mesure appropriée, quelle a été l'ampleur du gain de productivité?

Les développeurs de 2014 produisent-ils des logiciels moins de 10 fois plus vite que leurs homologues de 1986?

J'imagine qu'il y a eu au moins une amélioration de l'ordre de grandeur de la productivité depuis lors. Mais pas en mettant à profit un seul développement, que ce soit en technologie ou en technique de gestion.

Les augmentations de productivité sont dues à une combinaison de facteurs. Note: Ceci n'est pas une liste complète:

1. Meilleurs compilateurs
2. Des ordinateurs beaucoup plus puissants
3. Intellisense
4. Orientation d'objet
5. Orientation fonctionnelle
6. Meilleures techniques de gestion de la mémoire
7. Vérification des limites
8. Analyse de code statique
9. Frappe fort
10. Tests unitaires
11. Meilleure conception du langage de programmation
12. Génération de code
13. Systèmes de contrôle de code source
14. Réutilisation de code

Etc. Toutes ces techniques se combinent pour produire des gains de productivité; Il n'y a pas une seule balle d'argent qui ait jamais produit une accélération de l'ordre de grandeur.

Il est à noter que certaines de ces techniques existent depuis les années 1960, mais qu’elles n’ont été largement reconnues et adoptées que récemment.

La réponse de Robert Harvey est bonne, mais je pense qu'il a laissé de côté la principale raison pour laquelle les programmeurs sont plus productifs que jamais: la disponibilité généralisée des bibliothèques de logiciels.

Quand j'ai commencé ma carrière, il n'y avait pas de STL, .NET, QT, etc. Vous aviez du C ou C ++ brut, et c'était à peu près tout.

Des tâches qui prenaient des jours, des semaines ou des travaux (analyse XML, connexions TCP / IP, communication HTTP) peuvent désormais être effectuées avec quelques lignes de code C #. C’est là que nous avons obtenu de meilleurs ordres de grandeur en termes de productivité globale des développeurs.

Notre produit actuel utilise une structure de fenêtre d'ancrage que nous avons achetée auprès d'un fournisseur. Cela me permet d’avoir une interface utilisateur de fenêtre d’accueil entièrement fonctionnelle en quelques minutes. Je frémis à l'idée de ce qu'il faudrait faire pour utiliser l'API win32.

Par souci d'argumentation, je suis en désaccord avec l'affirmation de Fred Brooks .

Il y a eu une amélioration de la technologie qui permettait à elle seule une amélioration de l'ordre de grandeur de la productivité: Internet , et plus précisément la disponibilité progressive de la connexion Internet dans chaque foyer au cours des deux dernières décennies.

Pouvoir trouver instantanément une réponse à presque tous les problèmes que vous pouvez rencontrer en tant que développeur permet une augmentation considérable de la productivité. Je ne sais pas comment sélectionner le nième élément de JQuery? La recherche Google conduit à une réponse à la question exacte sur Stack Overflow . Je ne sais pas comment utiliser overflowen CSS? Le MDN de Mozilla est ici . Vous avez oublié quel virtualmot-clé signifie en C #? Google aide encore.

Quand j'ai commencé à programmer, je n'avais pas Internet. J'avais des livres, ainsi que de la documentation au format numérique stockée localement, mais la recherche dans les livres et la documentation était un processus lent. Peu importe le nombre de livres que j'avais, il y avait de nombreux problèmes qui n'étaient pas mentionnés.

Plus important encore, presque tous les problèmes que vous rencontrez ont déjà été rencontrés par quelqu'un d'autre auparavant. Internet aide à trouver les personnes qui ont eu cette erreur et qui l’ont résolue avec succès. Ce ne sont pas des informations que vous retrouvez dans des livres ou des documents officiels tels que MSDN. Au lieu de cela, ces informations se trouvent généralement:

• Sur Stack Overflow, évidemment. Par exemple, je n'ai vu aucun livre qui mentionne ce problème .

• Dans les blogs. J'ai trouvé beaucoup d'aide sur les blogs lorsque j'avais des problèmes particuliers, que ce soit avec la configuration WCF ou un serveur proxy qui ne démarre pas ou un bug cryptique lors de l'utilisation d'une API spécifique sur une machine avec une culture différente de en-US.

• Dans les rapports de bugs concernant les logiciels open source. Par exemple, cela a été très utile récemment lorsque j'ai essayé d'utiliser le MAAS d'Ubuntu et lorsque j'ai utilisé PXE. Vous ne trouvez pas ce genre d'information dans les livres non plus.

L'importance de la disponibilité immédiate d'une réponse à la plupart des problèmes que l'on peut rencontrer est particulièrement visible si l'on prend en compte le fait que la plupart du temps qu'une équipe consacre à un projet est consacrée à son entretien .

• Internet n'aide pas beaucoup pendant les phases d'architecture et de conception (Programmers.SE pourrait aider, mais il serait beaucoup plus utile pour un architecte de lire des livres sur l'architecture et le design, d'apprendre les modèles de conception, etc.).

• Cela commence à être utile pendant les étapes de test et de mise en œuvre, lorsque des problèmes réels se posent.

• Mais la plupart des problèmes apparaissant lors de la maintenance, c’est là où l’aide d’autres personnes par Internet apparaît cruciale . Exemple de base: un service WCF fonctionne parfaitement sur ma machine , mais échoue sans exception aucune lorsqu’il est déployé en production, alors qu’il fonctionnait depuis deux semaines. C'est ce qui m'est arrivé et je suis reconnaissant aux auteurs de blogs et à la communauté Stack Overflow de m'avoir aidé à résoudre le problème en quelques heures plutôt qu'en quelques semaines.

Cela justifierait-il une augmentation de 10 fois la productivité? Difficile à dire.

• D'une part, il existe des cas où vous trouvez une réponse immédiatement, alors que vous auriez pu passer des jours à la chercher seule (ou être obligé de réécrire une grande partie de l'application).

• D'autre part, la productivité globale s'est améliorée en fonction de plusieurs facteurs, tels qu'une meilleure gestion de projet (Agile, TDD, etc.), une meilleure gestion d'équipe (une gestion radicale de Stephen Denning), de meilleurs outils (débogueurs, profileurs). , IDEs, etc.), un meilleur matériel (non, je ne serais pas très productif si je devais écrire dans Assembler pour un processeur lent et une RAM très limitée), etc.

Je dirais qu'Internet est un très bon candidat. StackOverflow et Google sont les outils les plus puissants du développeur. Partage instantané des connaissances à l'échelle mondiale! De nos jours, vous n'avez pas besoin de connaître les réponses, vous devez seulement savoir comment les connaître - et c'est un substitut parfaitement adéquat qui permet aux développeurs de passer moins de temps à lire et à plus de temps à coder, et donc à être productif. Cela signifie que tous les programmeurs du monde ont accès à toutes les réponses et qu’il leur suffit de savoir comment poser les bonnes questions.

Je suggérerais que les tendances nous entraînant dans la direction opposée (c.-à-d. Vers une productivité inférieure) sont au moins aussi fortes que les tendances que vous avez posées. L’expérience de développement d’outil de développement client / serveur tel que VB6 ou PowerBuilder se rapproche beaucoup de l’idéal du «développement rapide d’applications» (RAD). Vous devez dessiner vos formulaires, et il y avait des crochets évidents pour votre code procédural ou SQL.

Le développement Web, du moins au début, a détruit un grand nombre de techniques et d’infrastructures qui rendaient ces choses possibles, et de nombreux développeurs client / serveur ont tout simplement cessé d’être des développeurs ou se sont cramponnés à VB6, par exemple.

La transition vers un développement Web fortement axé sur le client a été une autre expérience de brûlure sur brûlure; Microsoft revenait à l’idéal RAD avec WebForms, puis il est rapidement tombé en disgrâce. Au lieu de cela, les développeurs devaient abuser de l’infrastructure (par exemple, XMLHttpRequest, qui est rarement utilisé pour XML) et, sinon, se contenter d’un faible niveau d’abstraction afin de rendre leurs sites Web plus interactifs.

Il y a de bonnes raisons derrière toutes ces transitions, et il n'est pas juste de comparer un processus ayant abouti à un .EXE natif (nécessitant une installation et une gestion chez chaque client) au développement Web, et il n'est pas tout à fait juste de comparer un processus reposant fortement sur sur les publications avec un qui donne une expérience plus transparente. Mais je dirai que les pratiques en vogue aboutissent à des processus de pensée étonnamment bas chez les personnes qui ont manqué le client / serveur, le RAD, etc. Les boutons client / serveur fonctionnaient à merveille et il n’était certainement pas nécessaire de s’inquiéter des canaux de données sous-jacents qui transmettaient les données aux gestionnaires d’événements qui ont rendu cela possible.

À l’inverse, les développeurs plus contemporains ont tendance à penser que ceux d’entre nous qui avons fait du développement client / serveur (ou même du développement Web basé sur le postback) ont tendance à recourir à des raccourcis (ce qui est mauvais). C'est compréhensible, mais je pense toujours que le développement actuel est étonnamment bas et que l'époque de la recherche d'une "solution miracle" semble avoir cédé la place à l'ère de la dérision de ceux d'entre nous qui remettons en cause la sagesse de l'exploitation fondre notre propre avance.

La technologie a beaucoup évolué et nous avons maintenant tout ce que Robert Harvey énumère dans sa réponse, mais:

• Le problème semble être l' évolution des exigences . Le client sait qu'il n'y aura pas de gaspillage de matériaux lors de la modification des exigences d'un projet de logiciel. Ce genre de changement d'exigence ne se produit presque jamais une fois qu'un projet du monde physique comme un bâtiment est à moitié terminé.

• Un autre aspect important est le fait que la programmation continue d’être un travail très manuel . Rarement, voire jamais, le code généré par RAD entre en production sans être modifié à la main d’abord.

• Le code reste très complexe et cette complexité ne semble pas diminuer avec les nouvelles technologies.

• Le taux de délais non respectés ou de dépassements de budgets reste supérieur à celui des autres disciplines et souvent, une dette technique est contractée pour les respecter, générant ainsi des coûts cachés.

• Ce qui est arrivé sans aucun doute, c’est qu’il y a eu compartimentage . La quantité de technologies à connaître est telle que les programmeurs ont dû se spécialiser dans un petit nombre de technologies pour devenir vraiment bons, exigeant différents types d’experts pour mener à bien un projet de grande envergure.

• Une chose qui parle de complexité logicielle est qu’alors qu’il existe littéralement des centaines de constructeurs automobiles dans le monde, la liste des entreprises capables de créer et de maintenir un système d’exploitation (de bureau, mobile, embarqué ou autre) se compte avec les doigts de vos mains.

• Tout ce qui précède a créé une situation dans laquelle il n'y a pas assez de personnes qui étudient pour devenir programmeurs , de sorte que les gouvernements ont créé des campagnes pour motiver davantage d'étudiants à s'engager dans cette voie.

• L’un des exemples de la maturité de l’industrie du logiciel est que les licences logicielles continuent d’indiquer que "<companyX> ne fait aucune déclaration concernant l’adéquation de ce logiciel à un usage particulier. Il est fourni" en l’état "sans" garantie expresse ou implicite ". Imaginez un fabricant de matériel informatique affirmant que son produit ne convient à aucun but particulier. C'est l'état de l'art en ce moment.

Alors que l'on peut discuter avec des métriques spécifiques (c'est-à-dire, les choses ont-elles été améliorées par un facteur de 9,98?), Je dois (en quelque sorte être un vieil homme) être d'accord avec le sentiment général du commentaire de Brooks.

Premièrement, très peu de technologies véritablement nouvelles ont été inventées depuis peut-être 1970. Oui, les circuits intégrés sont devenus plus longs, plus bas et plus larges, et la fibre de verre a amélioré les vitesses de communication, mais chaque pas en avant en entraîne un.

La technologie du compilateur a permis une amélioration environ 10 fois de la "productivité" des programmeurs par rapport à 1970, lorsque la fonction des chiffres est divisée par le temps de codage réel, mais la prolifération de nouveaux langages ou environnements de programmation "révisés" signifie que le programmeur moyen dépense de plus en plus temps en mode "rattrapage" et moins en activité productive. Apple, Google et Microsoft génèrent tous de nouvelles "mises à niveau" substantiellement incompatibles dans leurs environnements à un taux légèrement inférieur à celui qui provoquerait une révolte parmi leurs serfs, leurs programmeurs. De même, HTML / CSS / Javascript / tout ce qui devient de plus en plus complexe.

À une époque, la vitesse à laquelle la documentation pouvait être produite et diffusée aurait limité et limité toute cette "innovation", mais, grâce à Internet, une documentation rigoureuse n'est plus vraiment nécessaire - il suffit de casser les fonctions et de faire appel aux blogueurs pour dénicher les détails et les rendre disponibles.

Ajoutée: J'y réfléchis depuis hier, et en particulier au projet sur lequel j'ai travaillé de 1978 à 2008 environ. Ce projet (IBM System / 38 et ses successeurs) était assez unique en ce sens que dès le début, les efforts fait pour en contrôler la complexité (l’une étant la division du logiciel en deux parties à peu près égales, avec une interface "machine" entre elles). Dans le domaine particulier où j'ai travaillé, plusieurs de mes collègues étaient également consacrés au contrôle de la complexité (bien que nous n'utilisions pas ce terme à l'époque). Le résultat a été un produit qui (au début) était assez robuste et un "succès" avec les clients à peu près du git-go. Et ce fut un plaisir de travailler - comme jouer dans un orchestre bien entraîné.

Bien sûr, au fil des années, la complexité s'est insinuée, généralement à la demande des planificateurs et des gestionnaires de marché qui n'avaient aucune idée de la maîtrise de la complexité (ce qui est différent du simple maintien de la simplicité). Je n’ai pas l’impression que cela était inévitable, mais il était impossible de l’empêcher dans cette affaire sans un responsable (comme le faisait à l’origine Glenn Henry) pour repousser les forces de la confusion.

Une grande partie de ce que nous avons appris dans la pratique du génie logiciel dans les plus de 30 ans est de la forme « technologie X peut accélérer le développement initial de nouveaux logiciels, mais si vous ne passez pas autant ou plus de temps à penser à propos de la façon et quand vous l'utiliserez comme vous l'avez économisé, à long terme, votre application deviendra un véritable marasme de dette technique, ce qui vous coûtera plus cher en temps et en efforts de maintenance. "

Les technologies qui tombent sous ce rasoir incluent: langage d'assemblage codé à la main, compilateurs, interpréteurs, bibliothèques de procédures, programmation impérative, programmation fonctionnelle, programmation orientée objet, allocation de mémoire manuelle, récupération de place, types statiques, types dynamiques, portée lexicale, portée dynamique , pointeurs "sûrs", pointeurs "peu sûrs", absence de pointeurs en tant que concept de langage, formats de fichier binaires, formats de fichier à balisage structuré, macros, modèles, évitement des macros et des modèles, mémoire partagée, transmission de messages, threads, coroutines, boucles d'événements asynchrones, services distants centralisés, services distribués, logiciels installés localement, baies de stockage, listes chaînées, tables de hachage et arborescences.

Le fait que de nombreux éléments de la liste ci-dessus soient regroupés en groupes épuisant l’espace de solution connu est tout à fait intentionnel et devrait en soi vous dire quelque chose. On pourrait soutenir que les seules améliorations sans équivoque et systématiques apportées à la praxis depuis la première mise sous tension du Z3 sont la programmation structurée en blocs (par opposition au code spaghetti) et la protection de la mémoire (garçon, est-ce que je ne manque jamais les jours où une faute de frappe pourrait prendre tout mon ordinateur).