Si l’optimisation logicielle était prioritaire, une plus grande partie du monde pourrait fonctionner sur du vieux matériel
(twitter.com/ID_AA_Carmack)- Si l’optimisation logicielle devenait une vraie priorité, plus de systèmes qu’on ne l’imagine pourraient fonctionner même sur du matériel ancien
- Si les signaux de prix du marché s’appliquaient à des ressources de calcul rares, la pression pour produire des logiciels plus efficaces augmenterait
- Un exemple serait de reconstruire des produits fondés sur des langages interprétés et des microservices sous forme de base de code native monolithique
- Mais sans calcul ultra bon marché et hautement scalable, expérimenter et lancer des nouveaux produits innovants pourrait devenir beaucoup plus rare
- L’optimisation des performances ne suffit pas à elle seule : un calcul peu coûteux et scalable détermine la fréquence des expérimentations et des lancements de produits
Expérience de pensée : priorité à l’optimisation
- Si l’optimisation logicielle était une vraie priorité, plus de systèmes qu’on ne l’imagine pourraient fonctionner sur du matériel ancien
- Si les signaux de prix s’appliquaient fortement à des ressources de calcul rares, le marché exigerait des logiciels plus efficaces
Modes de mise en œuvre possibles et limites
- Un exemple serait de reconstruire des produits fondés sur des langages interprétés et des microservices sous forme de base de code native monolithique
- Toutefois, sans calcul ultra bon marché et hautement scalable, les nouveaux produits innovants pourraient devenir bien plus rares
1 commentaires
Avis sur Hacker News
On peut soutenir que le marché achète des logiciels bogués et inefficaces aussi volontiers que des logiciels bien finis, et que l’un des deux est le logiciel le moins cher à produire
Cela ressemble à l’histoire du « marché des lemons ». Le marché vend tous les produits comme s’ils étaient de haute qualité, mais en abaisse discrètement la qualité pour réduire le coût marginal. Les acheteurs ne pouvant pas distinguer la haute qualité de la basse qualité avant l’achat, la demande devient artificiellement similaire ; la cause est l’asymétrie d’information
C’est déjà le cas avec l’IA, et cela va empirer. Les utilisateurs ne savent pas faire la différence entre une application de machine learning sophistiquée et le fait d’appeler IA le programme d’essorage d’un lave-linge. Le label IA crée à lui seul une prime de prix, et les utilisateurs finissent par payer leur lave-linge beaucoup trop cher
Surpayer un logiciel médiocre parce qu’on croit qu’il a été conçu et écrit par des ingénieurs et des experts, c’est au fond la même chose. 99 % des logiciels sont écrits par des IC1 à IC3, et dans la plupart des entreprises tech, un seul QA est le seul mécanisme qui améliore la qualité au-delà du simple « critères d’acceptation remplis ». De temps en temps, une bande de stagiaires récite l’incantation « LGTM », mais même cela reste rare
https://www.lg.com/uk/lg-experience/inspiration/lg-ai-wash-e...
J’étais convaincu qu’un meilleur produit convaincrait les gens et connaîtrait une croissance virale, mais ce n’est pas ce qui s’est passé. Il y a bien eu de la croissance, mais elle était si lente que les fonds se sont épuisés au bout de quelques années avant d’atteindre le seuil de rentabilité
Ce que j’ai compris, c’est que sur un marché concurrentiel, un coût faible, et donc une qualité plus faible, constitue un avantage concurrentiel. Plus un produit prend de l’ampleur, plus la pression pour réduire les coûts augmente ; les gens veulent du bon marché, donc quelqu’un finit par réduire le « coût », c’est-à-dire la qualité, pour vendre moins cher. Une entreprise ne paie que le minimum nécessaire pour survivre et dégager un bénéfice
Il arrive qu’une jeune entreprise veuille produire de la haute qualité, ou augmente brièvement ses dépenses, mais au final une dynamique la fait glisser vers une médiocrité stable. C’est un peu différent du marché des lemons, et cela semble mener moins à un effondrement du marché qu’à de la médiocrité un peu partout
Pourtant, si l’on demande à une personne moyenne de choisir entre Slack et Weechat, un client IRC rapide, elle considérera probablement comme de moindre qualité celui qui a une UI de terminal, pas d’appels vidéo, pas d’intégrations webhook, pas d’avatars personnalisés ni d’emoji
La performance est aussi une fonctionnalité. L’une des grandes raisons pour lesquelles Internet Explorer a été supplanté par Chrome est que Chrome était beaucoup plus rapide à sa sortie, et si les développeurs Python migrent rapidement vers uv/ruff, c’est aussi grâce aux gains de performance. Mais quand le lancement de Slack prend 5 secondes au lieu de 10 ms, très peu de gens s’en soucient
Cela arrive avec les logiciels pleins de bugs, mais en général les gens veulent payer moins cher et acceptent quelques bugs au passage. Il suffit de se demander combien il faudrait facturer pour que chaque ligne de code soit relue par plusieurs ingénieurs et que l’on consacre beaucoup de temps à une QA stricte
Quand je vivais à Padoue, j’ai créé un logiciel pour une petite librairie ; comme c’était pour un ami, je l’ai fait rapidement et je n’ai pas demandé cher. Ce n’était pas parfait, mais quand un problème survenait je le corrigeais, il n’y en avait pas beaucoup, et mon ami était satisfait de l’accord. Comme il savait qu’il payait peu, il faisait aussi preuve de patience
J’ai dit à plusieurs reprises que si notre équipe disait à un client : « le projet est terminé, mais il contient autant de bugs et de cauchemars d’UI que cette plateforme de back-office », nous serions réprimandés, rétrogradés ou licenciés
Cela inclut même des entreprises comme Google, qui manquent de support humain. Le support prend plusieurs formes : des informations comme la documentation, les vidéos, les blogs ; des personnes qui aident, comme dans « Maman, Google s’utilise comme ça » ; la prise en charge des environnements d’usage comme les systèmes d’exploitation, les navigateurs et les formats ; et aussi le fait de soutenir ma manière même de travailler, comme Excel
Enfin, il y a les vraies personnes. C’est le facteur numéro un qui permet même au pire ERP de la planète de survivre. Le marketing et les ventes signalent aussi qu’il existe du support. Pour un client entreprise, ne voir que des ingénieurs peut être un mauvais signal. Les développeurs sont souvent incapables de faire autre chose, et cet autre chose est justement un support important
Même un bon produit meurt sans support. Pour lutter contre un produit plus mauvais, il est judicieux de réduire les besoins de support — bugs, problèmes de performance, plateformes — afin de diminuer les coûts de mon équipe, mais il faut impérativement ajouter du support sur d’autres dimensions. Pour une petite équipe, le plus simple est d’affecter la ressource de support la plus rare : des personnes ; ensuite, il faut de la créativité
Il faut aussi bien communiquer ses avantages. Certaines personnes accordent plus d’importance à certains types de support, par exemple « pouvoir disposer du code vs produit propriétaire ». Beaucoup préfèrent un produit propriétaire avec du support plutôt que du code
Depuis 1980, on peut considérer que la puissance de calcul a été multipliée grosso modo par 1000.
Même si la vérification des bornes des tableaux dynamiques coûtait 5 %, en pratique ce serait bien moins que cela, et si on l’activait partout, les ordinateurs ne seraient « que » 950 fois plus rapides.
Si l’on retournait en 1980 et qu’on demandait aux gens de choisir entre « un ordinateur 950 fois plus rapide, sans une grande catégorie de vulnérabilités liées à la sûreté mémoire, et avec un débogage plus facile de plusieurs ordres de grandeur » et « un ordinateur 1000 fois plus rapide, mais avec des logiciels toujours pleins de bugs, voire pires, et un débogage cauchemardesque », ils auraient déjà été sidérés par un facteur 950.
Pourtant, c’est la seconde option que nous avons choisie, et personnellement je pense que le camp des partisans du x1000 a gâché la vie du reste du monde.
Au final, quand ils les ont optimisés pour tourner efficacement sur Sparc 20, cela a créé les bases du succès de l’entreprise sur un marché plus large. L’optimisation doit être traitée comme un avantage concurrentiel, et dans certains cas c’est peut-être même le plus important.
Imposer la vérification des bornes fait donc perdre à ce langage sa compétitivité sur certaines tâches.
Dans la grande majorité des cas, cela n’a aucune importance et coûte bien moins que 5 %. Je pense qu’une bonne solution consiste à séparer les zones sûres/non sûres, ou générales/performantes.
Les CPU grand public sont plutôt 1 à 2 millions de fois plus rapides que les machines des années 80. Pour quelques centaines de dollars, on peut encore acheter un PC de bureau reconditionné appartenant à la catégorie du million de fois plus rapide.
Le fait que les ordinateurs actuels soient lents, ou donnent l’impression de l’être, ne vient pas simplement du fait qu’ils sont lents, et pourtant cela arrive. Les langages de script qui allouent sans cesse de la mémoire pour de petites opérations, et qui suivent des pointeurs pour chaque variable à cause du typage dynamique, en sont une partie de l’explication ; il y a aussi des gens qui utilisent des programmes extrêmement inefficaces dans des environnements déjà mauvais.
La plupart des programmes actuels sont écrits non pas comme les utilisateurs voudraient qu’ils le soient, mais comme leurs auteurs ont envie de travailler. Beaucoup de gens n’ont aucune notion d’optimisation ni d’intuition sur ce qui s’exécute plus vite ; une fois que ça marche, ils se disent : « ce programme a cette vitesse-là ».
L’idée même que le même logiciel puisse être plus rapide relève d’un état d’esprit de niche, et même sur Hacker News tout le monde ne pense pas ainsi.
Les langages à ramasse-miettes utilisent souvent plusieurs fois plus de mémoire. Ils ne libèrent pas immédiatement la mémoire qui n’est plus utilisée et, dès le départ, ont aussi tendance à nécessiter davantage d’allocations.
Travailler chez Google et Facebook m’a fait prendre conscience à quel point le matériel est bon marché et, dans la plupart des cas, à quel point l’optimisation du code a peu de valeur.
Google a commencé il y a plus de dix ans à gérer l’utilisation des ressources de ses data centers, et chaque projet avait des budgets en cœurs CPU, espace disque dur, stockage flash, broches de disque, mémoire, etc. Ces ressources étaient globalement convertibles entre elles, ce qui permettait de voir leurs coûts relatifs.
À l’époque, le stockage flash coûtait environ 20 fois plus cher que le disque dur, mais à cause des goulets d’étranglement liés aux broches, il était souvent moins cher en coût total.
Tout cela pouvait être converti en « mili-SWE », c’est-à-dire un millième de l’effort d’un SWE travaillant pendant un an. Un projet pouvait économiser du matériel et recruter davantage, ou recruter moins et obtenir plus de matériel dans son budget actuel.
Je ne me souviens plus exactement de combien de cœurs CPU équivalaient à un SWE, mais il me semble que c’était plusieurs milliers. Si l’on passe une année de SWE à optimiser tout un projet sans économiser 5000 cœurs CPU, c’est une perte nette.
Les très grands projets en consommaient bien davantage, donc l’optimisation avait du sens, mais dans beaucoup de cas elle n’était pas appropriée, surtout si le code écrit avait de fortes chances d’être remplacé un jour.
En revanche, le Web souffre d’un problème général d’utilisabilité. Le Web ne devrait pas consommer autant de ressources qu’aujourd’hui. Si vous connaissez quelqu’un qui a fait de la saisie de données, vous savez que la souris est assez inefficace. Il y a 30 ou 40 ans, les terminaux en mode texte offraient des interfaces très efficaces tout en consommant très peu de ressources.
Je pensais qu’un jour le Web serait « résolu », avec une stack technique généralement attendue, puis qu’on passerait à d’autres problèmes, mais cela ne s’est pas produit. Il y a toujours le « framework de la semaine », et on fait des choses idiotes comme réimplémenter dans le code utilisateur des barres de défilement qui ne fonctionnent pas correctement avec la molette de la souris. Je ne sais pas comment ce problème pourrait être résolu, ni même s’il peut l’être.
Google a consacré des efforts énormes aux deux autres aspects de la performance : la latence et le taux d’utilisation global des machines. Dans les deux cas, c’étaient des directives venues d’en haut, qui ont absorbé le temps et l’attention de milliers d’ingénieurs, avec un coût salarial important.
Mais si les machines sont la contrainte, même si chaque cœur est bon marché, on ne veut pas les laisser inactives sans raison. Le coût d’opportunité d’attendre la construction d’un nouveau data center est élevé. Si l’usage est très sensible à la latence, réduire les millisecondes a du sens non pas pour réduire les coûts matériels, mais pour améliorer les métriques business.
L’évaluation doit se faire au coût marginal. Même si cela n’économise que quelques centimes par an pour chaque dollar, il vaut mieux qu’un ingénieur fasse ce travail plutôt que de rester inoccupé.
Le problème est que presque personne ne raisonne ainsi. Les décisions n’ont rien à voir avec un calcul économique, et la plupart se contentent d’imiter « ce que fait Google ». Cela explique beaucoup de dysfonctionnements.
Mais une entreprise ordinaire, même grande, n’est pas à ce niveau. Cela ressemble à un exemple typique de « Facebook/Google/Netflix et consorts appartiennent à une catégorie à part, et la plupart de leurs pratiques ne fonctionneront pas chez vous ».
On peut imaginer un univers parallèle où les ressources humaines seraient dirigées vers l’optimisation, mais cet univers serait totalement différent du nôtre. Un ingénieur de plus sur l’optimisation, c’est un ingénieur de moins sur le développement de fonctionnalités. Pour quoi faire ? Économiser quelques cycles CPU ? Allons bon.
Rien qu’au titre, je pensais que Carmack critiquait les logiciels mal optimisés et plaidait pour améliorer les performances sur du vieux matériel.
En réalité, le tweet ne dit ni l’un ni l’autre : il traite d’une expérience de pensée où les progrès du matériel s’arrêtent, et conclut que « sans informatique évolutive à très bas coût, les nouveaux produits innovants deviendraient naturellement bien plus rares ».
https://news.ycombinator.com/item?id=43967208
https://threadreaderapp.com/thread/1922015999118680495.html
Au contraire, on a vu assez peu de grandes innovations depuis 18 ans après le smartphone, et je pense que c’est parce que le capital s’appuie sur les progrès du matériel pour vendre aux consommateurs des produits qui, fondamentalement, ressemblent à ceux qu’ils possèdent déjà.
Évidemment, je n’ai pas pu lire au-delà du premier tweet.
Il y aurait une stagnation, mais pas une stagnation durable.
Si l’on peut recruter des gens sur des langages moins complexes et les rendre productifs, le marché du travail s’élargit et les coûts baissent.
Dans le texte original, Carmack affirme en substance : « les bons développeurs intelligents coûtent cher, et comme il y a plus important à faire, on ne paie pas pour optimiser le code et les systèmes jusqu’au bout, donc les logiciels sont lents ».
Cela implique donc que si les bons développeurs devenaient soudain très bon marché, tout le monde pourrait les acheter et les affecter à l’optimisation, et beaucoup de logiciels pourraient brusquement devenir plus rapides. Dans ce cas, pourquoi de bons développeurs pourraient-ils soudain arriver sur le marché à bas prix ?
Ce serait bien si l’on pouvait prolonger la durée de vie du matériel de 5 ou 10 ans au-delà de l’« obsolescence programmée ».
On réduirait ainsi beaucoup les déchets électroniques, on laisserait les terres rares dans le sol et on ferait aussi fortement baisser les émissions de gaz à effet de serre.
Mais les forces du marché de la production logicielle ne paient pas pour ces externalités. Il est bien moins coûteux de sortir vite, tester et itérer que de planifier et concevoir pour la performance. Certaines organisations dans l’industrie du jeu vidéo ont trouvé la formule pour obtenir à la fois de bonnes performances et de bonnes ventes, mais cela ne s’est pas diffusé uniformément.
Dans les logiciels d’entreprise et grand public, il y a peu d’incitation à intégrer des critères de performance dans les exigences. On conçoit pour le niveau que les utilisateurs sont prêts à tolérer, et comme il faut continuer à livrer des changements et des fonctionnalités, on se garde autant de marge que possible. Chaque changement est une dette susceptible d’affecter les performances et la satisfaction utilisateur, donc on prévoit de la marge budgétaire pour absorber le taux d’erreurs.
C’est très différent de l’époque où l’on concevait et développait à huis clos « jusqu’à ce que ce soit prêt ».
Nous devrions avoir une économie centrée sur le soin et la maintenance, et aligner nos efforts macroéconomiques sur le bien de l’humanité entière plutôt que sur la richesse perçue de quelques-uns.
Si nous nous étions concentrés sur l’entretien des vieux véhicules, la réutilisation des vieux ordinateurs, etc., les décharges auraient été plus petites par rapport à la croissance.
Bien sûr, il existe probablement aussi une construction de théorie des jeux montrant que le préservationnisme est une stratégie objectivement inférieure.
Cela fait déjà plus de 10 ans qu’il est possible de faire tourner le moteur d’appariement des ordres d’une Bourse entière sur un seul thread.
Je pense qu’une certaine classe de capacité de calcul, celle du traitement de transactions strictement sérialisées, n’a pas progressé aussi vite que d’autres indicateurs le suggèrent. Ajouter 31 cœurs ne rendra pas un moteur d’appariement d’ordres plus rapide ; cela peut même le ralentir.
Si votre produit traite moins de quelques millions de transactions par seconde et cherche pourtant un cluster de machines, il faut reculer d’une quinzaine d’étapes et repartir de zéro.
La conception d’origine aurait encore satisfait 99 % des cas d’usage, et compte tenu de la puissance de calcul locale actuelle, on pourrait même faire tourner tout le marché sur une seule machine.
Est-ce parce qu’il n’y a pas assez d’autres calculs à faire en dehors du tri par temps et par prix ?
S’il fallait effectuer un traitement plus complexe par transaction, on ne pourrait pas en traiter autant. Cela dit, il est difficile d’imaginer quel traitement plus complexe serait nécessaire sans être du domaine.
C’est juste. C’est un problème économique, autrement dit un problème d’allocation des ressources
Il s’agit de choisir entre faire passer plus de temps à quelqu’un sur l’optimisation logicielle, ou lui faire développer davantage de fonctionnalités. Si la seconde option génère plus de cash, on lui fera faire ça ; si la première devient importante pour les flux de trésorerie, on lui fera faire ça
C’est un cas évident d’externalité négative que les éditeurs de logiciels imposent au grand public. La plupart des éditeurs ne supportent pas le coût réel de l’énergie, du temps perdu et des déchets électroniques supplémentaires, donc ils ne se soucient pas de l’optimisation
Dans beaucoup de cas, une optimisation poussée n’a pas grand intérêt, mais l’idée d’ajouter simplement des serveurs au lieu de réécrire est un triste constat
Je n’utilise pas la plupart des nouvelles fonctionnalités de macOS, Windows ou Android. Ce que je veux, c’est un environnement efficace pour exécuter des apps et des améliorations de sécurité. Plusieurs « améliorations », comme l’app Réglages de macOS, ne me satisfont pas vraiment
C’est pareil pour les logiciels de design. Je n’utilise pas la plupart des nouvelles fonctionnalités ajoutées par Adobe, et je pourrais être parfaitement heureux avec Illustrator ou Photoshop d’il y a 10 ans. Ce que je veux, c’est un logiciel moins obèse
Pour l’audio et la production musicale, les workflows s’améliorent encore, donc je veux bien de nouvelles fonctionnalités, mais pas au prix de l’efficacité
Pour les éditeurs de code, les fonctionnalités de VSCode me suffisent. Je n’ai besoin de rien de plus ; je veux de meilleurs LSP, mais ce n’est pas le cœur de l’éditeur. En revanche, j’aimerais que VSCode soit plus rapide et consomme moins de mémoire
L’optimisation logicielle a le même attrait. Mais si le problème se résume à « consacrer plusieurs heures d’ingénierie coûteuse à optimiser » contre « ajouter de la RAM bon marché », l’option la moins chère l’emporte. Parfois, le problème est suffisamment important pour que l’optimisation en vaille la peine
Le marché décidera quel choix mérite d’être poursuivi. Quand on atteindra les rendements décroissants de l’approche consistant à jeter plus de matériel sur le problème, on optimisera le logiciel. La loi de Moore ralentit, mais on ne semble pas encore en être là
Mais la réalité est plutôt l’inverse. Si le prix affiché est plus bas, ils préféreront aussi une version moins performante
Ce n’est pas tant une réfutation de Carmack qu’un exemple concret auquel je pense parfois
Les apps Electron se situent quelque part entre « tolérées » et « détestées » par les consommateurs à cause de leurs problèmes de performance, mais elles sont peut-être l’innovation unique qui a rendu l’usage d’un laptop Linux au travail réellement praticable. Par exemple, pouvoir rejoindre une réunion MS Teams sans rien installer est vraiment utile
Donc tout le monde se lamente qu’aujourd’hui rien n’est codé aussi finement que Winamp, mais oublie les trois premières lettres
Il aurait de bonnes chances de fonctionner aussi sous Linux, alors que les logiciels Electron sont médiocres sur toutes les plateformes
En 2010, je travaillais comme agent d’entretien tout en faisant en quelque sorte le responsable IT en activité secondaire
À l’époque, j’ai dit à l’entreprise que n’importe quel laptop des cinq années précédentes, grosso modo à partir de Nehalem, offrait assez de performances pour travailler sur des tableurs. C’était pratiquement tout ce qu’ils faisaient, et deux cœurs, 16 Go de RAM et un SSD SATA de 500 Go suffisaient. Seules quelques personnes du marketing avaient besoin de machines un peu plus puissantes, mais la différence n’était pas énorme, et ils ont économisé beaucoup d’argent en n’achetant pas les tout derniers laptops haut de gamme
Je n’y travaille plus, mais je suis convaincu qu’aujourd’hui encore ces ordinateurs devraient être parfaitement suffisants pour des tableurs. Les workflows n’ont pas beaucoup changé ; ce qui a changé, c’est le logiciel. S’ils ont continué à faire les mises à jour, je ne sais même pas s’ils peuvent « faire tourner » MS Windows 10 ou 11 aujourd’hui, mais l’alourdissement, et surtout les tableurs uniquement en ligne, ont très probablement fortement réduit la productivité
Leur connexion Internet était aussi catastrophique. Les options étaient soit une DSL asymétrique d’environ 16 Mbit à 300 dollars par mois parce que c’était « business », soit du câble Comcast 120 Mbit à 500 dollars par mois. Même 120 Mbit suffit à peine pour des tableurs uniquement en ligne, et 16 Mbit est clairement insuffisant. Le pire, c’est que si Internet tombe, l’activité s’arrête
Voilà concrètement le vol dont parlait un autre commentaire, et je suis entièrement d’accord. Il n’y a absolument aucune raison pour qu’un laptop qui sert à modifier et mettre à jour des tableurs au bureau exige Internet, des ressources de calcul et de stockage absurdes, ou une grosse bande passante
Les performances épouvantables des ordinateurs d’aujourd’hui n’ont aucune excuse, si ce n’est de transférer les coûts vers les clients, particuliers comme entreprises
https://news.ycombinator.com/item?id=43971960
Le monde ne tourne pas grâce à des logiciels élégants, rapides et sans bugs, mais grâce aux fonctionnalités
Pour l’utilisateur final, il n’y a pas de différence entre une fonctionnalité absente et un bug. Il n’y a pas non plus de différence significative entre une mauvaise performance qui fait prendre 5 minutes pour terminer une tâche et l’absence d’une fonctionnalité qui oblige l’utilisateur à faire la même chose manuellement pendant 5 minutes. Dans les deux cas, c’est « lent »
Si l’on continue à maximiser la valeur pour l’utilisateur final, on finit inévitablement par produire des logiciels lents et pleins de bugs. En plus, si l’on demande aux utilisateurs s’ils préfèrent moins de fonctionnalités en échange de plus de rapidité et de moins de bugs, étonnamment, ils répondent non. Plus important encore, dans le monde de l’entreprise, l’acheteur du logiciel n’est souvent pas l’utilisateur final, et ces acheteurs veulent davantage de fonctionnalités, moins de performance et d’élégance
À ensemble de fonctionnalités égal, utilisateurs et acheteurs choisiront le logiciel le plus rapide, le moins bogué et le plus élégant. Mais s’il manque ne serait-ce qu’une fonctionnalité, on perd. La raison de garder un logiciel rapide et élégant, c’est que c’est ainsi qu’on maximise les chances de pouvoir continuer à ajouter des fonctionnalités sans finir avec un produit moins riche fonctionnellement
Une solution rapide et élégante peut recevoir de bonnes critiques et des éloges pour son confort d’utilisation. Cela peut donc donner l’impression que c’est un facteur important. Mais au final, si elle ne permet pas de faire ce qu’on veut, on ne l’achète tout simplement pas. S’il y a une fonctionnalité clé nécessaire, on choisira un bazar lent, frustrant et plein de bugs
Il faut aussi se rappeler que Microsoft doit désormais traîner les utilisateurs, à coups de pied et de cris, vers la version suivante de Windows. Si on les avait laissés décider par eux-mêmes, beaucoup n’auraient jamais mis à jour après Windows XP. Et ce malgré les nombreuses nouvelles fonctionnalités attrayantes des versions suivantes
Je suis d’accord pour dire que les entreprises et les investisseurs veulent les fonctionnalités en elles-mêmes, mais les utilisateurs, clairement pas
Si c’était possible, plus personne ne mettrait plus rien à jour. Il suffit de voir à quel point Microsoft se démène pour pousser les gens à mettre à jour. Je n’ai jamais entendu quelqu’un dire qu’il voulait une nouvelle version de Windows, Office, Slack, Zoom, etc.
C’est aussi la raison pour laquelle tout, comme Photoshop, est forcé vers le cloud. La grande majorité des gens ne veulent pas des nouvelles fonctionnalités proposées, y compris les acheteurs en entreprise. La réponse pour maintenir le chiffre d’affaires consiste à faire en sorte que les gens achètent, que les fonctionnalités soient fournies ou non
Cela dit, les utilisateurs existants font déjà ce dont ils ont besoin avec le logiciel ; de nouvelles fonctionnalités peuvent donc leur permettre de supprimer un autre logiciel ou de faire quelque chose de nouveau. Mais si cette nouvelle tâche était vraiment extrêmement importante, ils auraient déjà trouvé un autre logiciel pour la faire, ce qui signifie qu’ils ont tenu jusque-là sans elle. Donc, si les utilisateurs existants étaient vraiment réflexifs, je pense qu’ils demanderaient d’abord des améliorations de performance, puis quelques petites améliorations
À l’inverse, les utilisateurs potentiels ne connaissent pas encore le logiciel, ou ont besoin d’une autre fonctionnalité avant de le trouver utile. Ce sont eux qui recherchent rationnellement de nouvelles fonctionnalités
Ainsi, la décision « fonctionnalités vs performance » est aussi un signal de la priorité des développeurs : ajouter de nouveaux utilisateurs ou satisfaire les utilisateurs existants. Il est naturel que les techniciens préfèrent la seconde option. Ils ont déjà joué à ce jeu et savent qu’ils veulent être prioritaires pendant la longue période d’usage réel, pas seulement pendant l’acquisition
Si des logiciels riches en fonctionnalités mais lents et pleins de bugs dominent le marché, c’est aussi parce que les entreprises donnent la priorité à la croissance. L’histoire regorge de beaux logiciels élégants que les utilisateurs regrettent, mais qui ne se sont pas diffusés assez largement pour que l’entreprise survive
Le compromis existe réellement dans les deux sens. La plupart des gens passent plus de temps comme utilisateurs que comme utilisateurs potentiels. C’est très probablement l’une des grandes raisons de la perception générale selon laquelle les logiciels et les ordinateurs d’aujourd’hui sont incroyablement médiocres
L’argent dépensé dans davantage de RAM et de meilleurs CPU pour les ordinateurs domestiques et de bureau permet de publier tous les logiciels qui tournent dessus à moindre coût et avec davantage de fonctionnalités