Faisaient plus moins de développement
Mes racines sont dans le développement de logiciels. J’ai écrit un logiciel fiscal, un micrologiciel et des serveurs SmartGrid, un code d’intégration d’entreprise pour de nombreux serveurs développés et achetés, un logiciel de cartographie, un micrologiciel de téléphone portable, la liste est longue. Le fait est que le développement est dans mon sang. Lorsque j’examine quelque chose qui a un impact sur le développement de logiciels, je l’aborde autant du point de vue d’un praticien que d’un analyste. Et voici beaucoup changement en cours dans le domaine du développement logiciel.
Pendant très longtemps, il existe des options qui réduisent la quantité de logiciels que nous développons. Et ces options sont souvent populaires. Il fut un temps où l’expression la plus courante dans l’informatique d’entreprise était Développer des systèmes de base, acheter des systèmes de support, et le message a suffisamment pénétré pour que nous n’ayons plus besoin de le dire. Il fut un temps où les entreprises concoctaient des systèmes aussi essentiels que le courrier électronique, certaines développant leurs propres systèmes, mais la plupart travaillant dur pour intégrer les offres disponibles. Nous avons complètement renversé cette équation, et maintenant presque personne n’envisagerait de consacrer des ressources informatiques importantes à la messagerie électronique. Pas sur le développement, pas sur l’intégration. Il y a bien sûr des cas d’angle qui ont des problèmes, notre industrie pourrait être définie comme une collection de cas d’angles vifs que nous n’avons pas encore lissés, mais peu, voire aucun de ceux qui lisent ce blog, ont eu à s’inquiéter de ces angles. Alors, changez numéro un : l’achat de solutions informatiques réussit massivement à réduire notre temps. Du CRM au courrier électronique en passant par la sécurité, nous utilisions beaucoup plus d’outils écrits par d’autres.
Il existe également depuis toujours des outils de génération de code. Alors que les plus connus étaient historiquement axés sur l’interface utilisateur, les 4GL essayaient généralement d’aborder le développement avec moins de code. Encore une fois, le temps, les échecs et les itérations nous ont donné des techniques de réduction de code utiles. Des instructions « if » préformatées que nous insérons simplement dans les variables à la génération d’API via des moteurs de génération de programme initiaux (parfois alimentés par l’IA) qui nous donnent du code pour démarrer un projet. Les exigences pour écrire du code sont moindres par projet.
Et le grand : Open source. Il existe des marchés entiers de logiciels pour lesquels il ne vaut pas la peine de développer des solutions car il existe de bonnes solutions open source sur le marché. S’il est populaire mais que même les fournisseurs ne peuvent pas se permettre de créer des solutions parce que tout le monde utilise bien la solution OSS, cela réduit la quantité de code développé. Il existe plusieurs entreprises dont l’ensemble du modèle commercial consiste simplement à offrir aux entreprises un service et une assistance sur OSS. Aucun développement nécessaire, même pour le vendeur. De grandes parties de toute application donnée que nous développons de nos jours sont basées sur l’open source que nous incluons pour résoudre une partie du problème. Nous avons eu des hacks et des échecs spectaculaires basés sur ce modèle, mais c’est indéniablement un catalyseur pour plus de solutions.
Avec tout cela (et sans doute plus comme l’API d’abord et la normalisation des API) réduisant la quantité de code développée, vous penseriez que les développeurs seraient moins occupés, n’est-ce pas ?
DevOps et Agile ont rationalisé notre développement et raccourci les délais de livraison pour les sous-ensembles d’un projet donné, mais n’ont pas et n’ont pas été conçus pour réduire la quantité de logiciels développés. En effet, bien au contraire. Avec des itérations plus rapides, d’autres pourraient être essayées.
Mais il est faux de penser qu’il y a moins d’efforts de développement. Il y a plusieurs raisons à cela, mais je vais me concentrer sur la plus importante. Les personnes investies dans l’entreprise, les chefs d’entreprise, etc. ont toujours eu un énorme désir refoulé d’améliorer les logiciels pour augmenter l’efficacité, la compétitivité, etc. Et l’informatique était le goulot d’étranglement. Agile/DevOps n’est en aucun cas parfait, mais ils offraient une soupape de surpression pour cette demande refoulée. Et nous y sommes depuis assez longtemps pour savoir que les itérations rapides en réponse à ces demandes inspirent plus de nouvelles idées, créant une autre itération. Il est donc peu probable que cela s’arrête. En effet, nous savons tous ce qu’est la dette technique, mais il semble y avoir un décalage entre le fait de savoir intuitivement que plus de code signifie plus de dette sous forme de frais généraux de maintenance. Les développeurs en font donc plus parce que l’organisation a de bonnes idées qui doivent être mises en œuvre, même si nous disposons de nombreux outils pour réduire l’effort de développement. Certaines organisations ont réduit leurs effectifs de développeurs, mais pas beaucoup. Et cela pourrait ralentir, mais c’est peu probable. Dans l’environnement hautement concurrentiel à venir, plus de fonctionnalités et de solutions seront souhaitées, pas moins.
Et vous serez là, continuant à le faire vibrer. Faites attention aux moyens de réduire davantage l’effort de code. Il s’agit d’un processus à long terme, mais l’objectif devrait être de réduire le taux de croissance du temps du personnel. Il est peu probable qu’il baisse dans l’ensemble, car les frais de maintenance et les nouveaux projets sont un nombre en constante augmentation, mais le ralentissement de la croissance aide les développeurs et les gestionnaires en activité à rester sains d’esprit et à prendre le temps de trouver de bonnes recrues.
Et continuez à faire plus et moins de développement.