Comment les «DevOps» sont en train de tuer les développeurs ?

Avec l'apparition du programmeur généraliste, on a vu naitre une nouvelle tendance que les Anglais surnomment «DevOps». Mais qu'est-ce donc qu'un «DevOps» ? C'est la contraction de «Développeur aux opérations», soit un développeur principalement centré sur les urgences, du maintien d'un site Web. Il devra s'occuper de remplir tous les rôles autour de lui dans son propre poste, soit l'analyste, la programmation, l'intégration, l'opérateur d'analyste, le QA, l'administrateur, la documentation et le DBA.

Pourquoi en est-on arrivé à cette nouvelle tendance de poste ? La première idée derrière, c'était qu'on voulait réduire le nombre de postes. Le calcul était simple, si le programmeur est occupé 55% du temps, que l'analyste était occupé 20% du temps, le DBA 15% du temps et le QA 10% du temps, alors on devrait pouvoir en conclure qu'une seule personne serait occupé 100% du temps et que les autres personnes ne sont plus nécessaires qu'on pourrait supprimer leur poste. Naturellement, l'entreprise tient pour acquis que le programmeur soit capable d'accomplir les tâches de tous les autres postes avec la même qualité !

D'où vient ce concept ? Les origines proviennent du manifeste Agile datant de 2001. C'est que dans l'état actuel des choses dans le domaine des technologies de l'information, un produit doit systématiquement repartir de zéro à tous les 2 ou 3 ans ! Hors, le problème c'est que les anciennes méthodes de travail, souvent plus fiable, sont, hélas, beaucoup plus longue a aboutir : Assez long pour que le produit soit désuet lorsqu'il est finalement terminé ! Pour contourner le problème du temps, on imagina Agile, soit l'idée de focaliser essentiellement sur l'essentiel et de ne pas développer les trucs moins utilisés. Ainsi, on reprenait l'idée que les ingénieurs de «Start-Up», ayant peu de ressources, ont imaginée pour livrer une première ébauche de projet !

Des exemples...

La théorie est naturellement magique ! Les entreprises ont trouvé une façon de réduire les coûts et livrer rapidement un produit. Inutile de vous dire, que cette façon de fonctionner est devenue rapidement populaire chez les entreprises ayant comme unique objectif de faire plus d'argent. Toutefois, la pratique est fort différente. On pourrait facilement imaginer que vous êtes quelqu'un ce joignant à une équipe de développement de 5 ans, 1 an après que le produit soit en production. Vous n'aurez aucun mal à changer des petits problèmes de base d'orthographe ou autre, mais lorsque vous aurez un vrai problème nécessitant des connaissances approfondies, vous ne pourrez pas évoquer que ce n'est pas votre spécialité, car il n'y a pas un intégrateur ou un DBA de disponibles par exemple. Le résultat qu'on retrouvera souvent, c'est que vous avez pris dix fois plus de temps qu'aurait pris la personne du poste supprimé.

De plus, souvent il s'agira d'un produit de catégorie «beta», n'ayant pas la moitié des problèmes de résolue, et dont le contrôle de qualité (QA) a carrément été supprimé du cycle, vous vous retrouverez donc toujours aux prises avec des urgences à régler au plus vite, chose plutôt anormale pour un produit ayant plus d'un an de fonctionnement en production !

Ce genre ce combinaison de poste qu'occupera un «DevOps», fait en sorte que le développeur n'écrit presque jamais du code, il est devenu programmeur 10% du temps. Et lorsqu'on lui demande de passer l'examen FizzBuzz, lequel est un problème de programmation de base qu'un programmeur devrait être en mesure de passer, il n'y arrive pas ! On finira par entendre dire, par la direction de l'entreprise, que les DevOps coûtent cher !

Conclusion

En conclusion, si l'idée c'est de livrer un prototype pour montrer qu'il est possible de réaliser un projet d'accord, mais que l'on considère qu'il s'agit d'une ébauche finale pouvant être montrée au client et aller en production, c'est assez dangereux ! Entre, le projet aura forcément beaucoup de petits bogues, un peu agaçant, mais disons acceptable selon le développeur du produit. De son côté, la sécurité sera pour ainsi dire, inexistante, puisque le client lambda ne voit pas les brèches, alors c'est considéré comme un développement inutile. Le point le plus surprenant d'entre tous, c'est que le DevOps ne connaitra pas son produit, car il n'y aucune expertise à aucun niveau des rôles qu'il occupe.

Voir également

Les contractants, comment réussissent-ils à écrit des programmes biodégradables ?
Articles - L'entreprise amateur !