Le « DevOps » et le développeur « FullStack » mettraient en danger le métier de développeur
Le constat inquiétant de Jeff Knupp

Le , par Arsene Newman, Expert éminent sénior
Jeff Knupp est un développeur chevronné basé à New York, aujourd’hui il revient dans un billet de blog sur les deux grandes tendances actuelles du développement logiciel à savoir : le concept de « DevOps » et le développeur de type « FullStack », ainsi que sur le danger qui guette le métier de développeur suite à l’avènement de ces tendances.

« Le DevOps est un concept qui vise une collaboration plus étroite et une combinaison des différents rôles impliqués dans le développement logiciel comme le rôle de développeur, de chargé d’opération ou encore de chargé d’assurance qualité, car les logiciels doivent être produits à un rythme effréné alors qu’au même moment le développement en cascade semble avoir atteint ses limites. »

« L’accroissement des responsabilités du développeur a donné lieu à un futur métier chimérique : le développeur « FullStack », un tel développeur est en mesure d’être le développeur, le chargé d’assurance qualité, l’analyste des opérations, l’administrateur système/BDD. »

« Mais alors d’où viennent ces concepts ? Des startups, mais aussi des adeptes des méthodes agiles. Dans le cas des startups, elles ont besoin de fonctionner de la sorte pour pouvoir survivre les premiers temps, malheureusement ces divers rôles techniques qui sont à la charge du développeur au sein d’une startup par manque de ressources, sont en passe de devenir le minimum requis pour un développeur. »

Alors, la question suivante surgit : Pourquoi le développeur peut jouer autant de rôles différents ? La réponse est simple selon Knupp : « Il existe une hiérarchisation des différents rôles prenant part au développement logiciel. Le développeur est au sommet de cette hiérarchie, suivi par l’administrateur système/BDD. Les chargés d’assurance qualité, des opérations et les coordinateurs de releases constituent la base de cette hiérarchie. »

Son explication ne s’arrête pas uniquement à cela : « Parce que chaque rôle est en mesure de faire le travail des rôles qui lui sont inférieurs dans la hiérarchie. Les startups nous l’ont appris. Mais cela ne marche pas dans le sens inverse, car les rôles inférieurs ne disposent pas du savoir-faire requis pour accomplir certaines tâches »

Quel est donc le danger qui guette le métier de développeur ? Pour le blogueur la réponse est évidente : « Quand le développeur est affecté à d’autres rôles, il n’y a plus personne pour assurer le développement ! » en même temps « Aucun des autres rôles, même lorsqu’ils sont combinés ne sont pas en mesure d’assurer le rôle de développeur ».

Cela conduit entre autre à la non-spécialisation du rôle de développeur, hors pour Knupp : « Nous sommes spécialisés pour une seule raison : les êtres humains ne sont pas capables de retenir autant de connaissances. Sans oublier que le basculement entre les rôles est coûteux pour le cerveau humain.» De plus, forcer les développeurs à prendre en charge des tâches supplémentaires normalement affectés à des spécialistes les conduit à :
  • Ne plus accorder autant de temps au développement ;
  • Gérer une quantité d’informations et de connaissances trop volumineuse ;
  • et enfin à Exploser.


Au final il est urgent de réagir face à cette situation et surtout de « Laisser les développeurs coder », de plus « il apparaît que les entreprises agissent comme si elles étaient des startups » hors « Toutes les entreprises ne sont pas des startups, les startups n’ont pas fait des développeurs des hommes à tout faire par choix, mais par nécessité. »

Source : Blog de Jeff Knupp
Et vous ?
Pensez-vous que le « DevOps » est une bonne chose pour le métier de développeur ? Pourquoi ?
Que faut-il faire pour endiguer ces tendances selon vous ?


Vous avez aimé cette actualité ? Alors partagez-la avec vos amis en cliquant sur les boutons ci-dessous :


 Poster une réponse

Avatar de randriano randriano - Membre éprouvé https://www.developpez.com
le 18/04/2014 à 12:24
C'est compliqué tout ça

J'ai travaillé sous la méthode agile depuis mes débuts notamment Scrum mais je ne suis pas du tout convaincu de son efficacité! Disons seulement que c'est une norme d'organisation du travail, je l'utilise, au moins, il y a du suivi mais que le projet se réalise bien ou plus rapidement, non ce n'est pas le cas!

Développeur fullstack! Je le suis étant donné que je fais du freelance mais en entreprise, c'est un avantage certes pour l'entreprise, un informaticien polyvalent mais c'est pas bon pour le développeur lui-même qui n'est plus aussi efficace qu'avant car il doit apprendre des tas de trucs.
Avatar de Dankin Dankin - Membre du Club https://www.developpez.com
le 18/04/2014 à 17:59
Et un développeur avec de bonnes bases de systèmes n'aura jamais le temps de se spécialiser pour être très bon sur la partie sysadmin.

Moyen partout. Bon nul part, c est bien le pb du développeur fullstack.
Avatar de Pierre-Yves Le Dévéhat Pierre-Yves Le Dévéhat - Membre régulier https://www.developpez.com
le 18/04/2014 à 20:12
Citation Envoyé par Arsene Newman  Voir le message
[B][SIZE="4"]
Cela conduit entre autre à la non-spécialisation du rôle de développeur, hors pour Knupp : « Nous sommes spécialisés pour une seule raison : les êtres humains ne sont pas capables de retenir autant de connaissances. Sans oublier que le basculement entre les rôles est coûteux pour le cerveau humain.» De plus, forcer les développeurs à prendre en charge des tâches supplémentaires normalement affectés à des spécialistes les conduit à :
  • Ne plus accorder autant de temps au développement ;
  • Gérer une quantité d’informations et de connaissances trop volumineuse ;
  • et enfin à Exploser.

Une chose est sûre : on ne peut pas être à la fois un "développeur chevronné basé à New York" et un expert en neurologie et autres sciences du cerveau et de la mémoire ! On nage dans les affirmations gratuites fleurant bon l'amateurisme.
Il reste largement à prouver que le "basculement" dont il est notamment question est "couteux" alors que les observations dans le milieu du travail en général ont largement prouvé depuis des lustres que la diversité est psychiquement bénéfique.
Pour ce qui est de retenir des connaissance, il faut se garder de considérer la mémoire comme un vase qui connaitrait une limite. Il s'agirait bien plutôt de l'inverse encore une fois : plus on apprend, plus notre cerveau est disposé à apprendre, c'est notable dans l'apprentissage des langues par exemple. Il me parait bien plus juste de considérer que la diversité des schémas de savoir développe d’avantage cette capacité à assimiler ainsi que les aptitudes créatives.
Avatar de Zefling Zefling - Membre émérite https://www.developpez.com
le 19/04/2014 à 0:34
En tout cas, quand je vois les annonces d'emploi, j'ai l'impression que l'on demande de plus en plus de chose au dév., j'en ai même vu où ça ressemblait plus à un mouton à 18 pattes (ex : spec, dév., base de données (remplir), graphiste, rédaction, traduction, communication sur les réseau sociaux, contact client, etc.) Je vois pas comment on peut réussir à tout faire correctement. Je vois bien ce que ça a donnée dans une petite boîte où j'avais tellement de casquettes, que le dév, c'est limite plus possible de l'assurer.
Avatar de Blopss Blopss - Candidat au Club https://www.developpez.com
le 19/04/2014 à 7:20
Salut,
Je crois qu'il n'y a pas besoin d'être dev "fullstack" ou de faire du DevOps pour être un developpeur submergé. Pierre-Yves a raison quand il dit que la diversité a du bon, par contre quand on switch de projet voire de type de tâche toutes les 15 minutes (si c'est pas 5), c'est invivable à long terme, et il n'y a pas besoin d'avoir fait du scrum pour être au courant.

A mon avis ce ne sont pas ces méthodes émergentes qui sont fautives, c'est le rythme. Il me semble qu'on peut faire du developpement agile sans être stressé (c'est même censé être un des buts à la base de la méthodo non?) et qu'on peut être stressé sans faire d'agile. Aujourd'hui le temps "réglementaire" n'est souvent pas laissé aux dev (aux genx) pour entrer dans leur tâche, et ils sont bien trop souvent interrompus.

Le bouquin "Rework" de 37Signals evoque entre autres l'idée de laisser aux développeurs des plages horaires fermées, où ils ne peuvent pas être interrompus : pas de demande de la part du pm, pas de réunion, pas de pause café, etc. Je rêve qu'on mette en place ce système là où je bosse...

Note : à la fin de l'article, il y a deux fois la même faute, "hors" à la place de "or".
Avatar de dahtah dahtah - Membre éclairé https://www.developpez.com
le 19/04/2014 à 10:51
En meme temps, y'a beaucoup de conneries dites sur le modele devops. Devops ca veut pas dire que tout le monde fait tout, mais que les devs et ops font partie de la meme equipe. Les specialites restent. C'est pas aprce qu'un gars de ops fait partie d'une equipe devops qu'il se met soudain a faire du dev pur.

L'utilite de devops, c'est que ca permet de prendre en compte les contraintes operationelles au debut des cycles de devs. Ca evite aussi, les "je mets en production sans gerer le passage a l'echelle", les gars de ops vont se lever a 3 heure du mat pour gerer tout ca. La responsabilite en cas de probleme comme de succes est partagee.

On applique ce modele au taf (je bosse pour une tres grosse boite, pas une startup), et ca marche plutot bien je trouve. On a change plusieurs designs des le debut a cause de contraintes operationnelles auxquelles on aurait pas pense.
Avatar de Laurent7601 Laurent7601 - Provisoirement toléré https://www.developpez.com
le 19/04/2014 à 11:00
Je suis d'accord et je trouve que le métier de développeur à l'heure actuelle est de plus en plus malmené.

Ca se voit lors de l'utilisation des apis que les développeurs ne peuvent pas se spécialiser et le développement donne souvent lieu à des apis instable car, ces apis peuvent très bien fonctionner sur certaines plateforme et pas sur d'autre, bref, je me souviens qu'on a eu pas mal de soucis avec ça et pas que dans le monde professionnel mais aussi dans le cadre de mes études.

Le développeur à l'heure actuelle doit se concentré sur trop de chose et ne peut pas se spécialiser dans un domaine. (J'ai d'ailleurs moi même appris un peu de tout dans le cadre de mes études j'ai été très vite amené à devenir développeur fullstack et à ne pas me spécialiser dans un domaine car j'ai appris le développement web, la gestion des bases de données et de système d'exploitation, développement en c++, le développement en java et même des langages plus ancien comme le cobol, prolog, la gestion de base de donnée, du droit, de l'économie, de la gestion d'entreprise, un peu d'anglais, etc..., bref je possède pleins de connaissances moyennes dans pleins de domaine et je ne suis pas spécialisé dans un domaine, si je veux me spécialisé je serai obligé de le faire moi même.)

Bref on part un peu dans tout les sens et on a du mal d'avoir un produit fini et correct surtout. (Mes études c'était un peu ça, c'était vraiment des études dans le but de créer une start up ou bien de devenir développeur dans une pme)
Mais peu on encore s'en sortir à l'heure actuelle si les choses continue ainsi ? (Ca, c'est la grand question mais moi personnellement je ne pense pas)
Avatar de Bousk Bousk - Rédacteur/Modérateur https://www.developpez.com
le 19/04/2014 à 20:46
Je vais prendre mon cas propre.
Développeur réseau, je m'occupe du développement côté serveur, mais aussi client.
Ce qui m'amène donc à faire du Python et du C++. Mais le client a du scripting en LUA, donc je fais aussi du LUA.
Puis on a de la persistance, donc une DB (MySQL en l'occurence), ce qui m'amène donc à faire du SQL, et donc endosser le brassard de DBA.
Mais les serveurs sont sur des machines propres, du FreeBSD, donc je bidouille un peu de FreeBSD.

Alors oui, finalement ça demande de nombreuses casquettes et compétences, on ne peut pas tout maîtriser, mais on connait tout et on retrouve le reste. Mais cela était déjà vrai lorsque je ne faisais que du développement dans un unique langage.

A l'inverse, si l'on demande une nouvelle fonctionnalité, je vois mal la chaîne:
- le DBA bidouille la DB
- le programmeur serveur récupère/insère en DB les données (déjà, il doit connaître de la DB, donc la casquette DBA prend son sens)
- le programmeur serveur envoit les données au client
- le programmeur client récupère les données du serveur (qui mieux placé sur le programmeur serveur pour connaître les données ? puisque c'est lui qui les envoit)
- le programmeur scripting récupère les données du client via l'interface de scripting (là encore, le programmeur client est bien placé, c'est lui qui les crée)
Donc que toute cette chaîne soit réalisée par une unique personne a du sens amha..

Maintenant, si les applis serveurs se plantent, est-ce que je vais attendre que l'admin réseau me balance les erreurs (avec éventuels aller-retours pour guider les recherches et récupérer les bonnes informations), ou bien je vais aller chercher moi-même ?
Avatar de Heptaeon Heptaeon - Membre habitué https://www.developpez.com
le 19/04/2014 à 22:31
Est ce étrange qu'un développeur voie une hiérarchie où le développeur est au sommet ?

Faire un peu de tout dans le but de comprendre l'autre, je trouve ça normale. Et ça n'empêche pas de se spécialiser dans son domaine préféré. Avoir le développeur et le DBA qui refuse de se comprendre l'un l'autre, ça se vois que trop souvent et c'est bénéfique pour personne...
Avatar de dlusignan dlusignan - Nouveau membre du Club https://www.developpez.com
le 20/04/2014 à 15:40
A l'inverse, si l'on demande une nouvelle fonctionnalité, je vois mal la chaîne:
- le DBA bidouille la DB
- le programmeur serveur récupère/insère en DB les données (déjà, il doit connaître de la DB, donc la casquette DBA prend son sens)
- le programmeur serveur envoit les données au client
- le programmeur client récupère les données du serveur (qui mieux placé sur le programmeur serveur pour connaître les données ? puisque c'est lui qui les envoit)
- le programmeur scripting récupère les données du client via l'interface de scripting (là encore, le programmeur client est bien placé, c'est lui qui les crée)
Donc que toute cette chaîne soit réalisée par une unique personne a du sens amha..

Le développeur "FullSatck" est un phénomène de "StartUp". La structure que tu viens de définir s'applique très bien par contre au sein d'une grosse équipe de développement. Pour un ERP, par exemple. Sinon, même au sein d'une grosse équipe de dev, le développeur est supposé pouvoir faire tout ça dans son environment de développement. Mais pour la production, il n'y a rien d'anormale à devoir travailler avec un DBA et un SysAdmin.
Offres d'emploi IT
Responsable technique - cto h/f
Pages Jaunes - Ile de France - Saint-Ouen (93400)
Développeur asp.net (C#)
TALENTIK - Québec - Quebec
Ingénieur génie mécanique informatique H/F
Dassault Systèmes SE - Ile de France - Vélizy-Villacoublay (78140)

Voir plus d'offres Voir la carte des offres IT
Contacter le responsable de la rubrique Accueil