Discussion :

[Arsene Newman]

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

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 ?

[randriano]

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.

[Dankin]

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.

[Pierre-Yves Le Dévéhat]

[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.

[Zefling]

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.

[Blopss]

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".

[dahtah]

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.

[Invité]

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)

[Bousk]

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 ?

[Heptaeon]

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...

[dlusignan]

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.

[Invité]

Je crois que je me suis mal fait comprendre :

C'est sûr que il faut aussi des connaissances dans d'autres domaines (car rien ne nous empêche de nous spécialisé par la suite selon les besoins de l'entreprise), ça c'est le principal atout du développeur fullstack. (Et d'ailleurs je ne regrette absolument pas de l'être, car ça m'aide beaucoup à réaliser mon projet actuel)

Ce qui est dangereux ce sont les grandes entreprises qui font pareil que les start-up afin de devoir moins engager. (C'est à dire un développeur ou deux pour tout)
Je ne sais pas pourquoi elles font ça, est ce parce qu'elle sont en difficulté à cause de la crise ou bien tout simplement pour s'en mettre plus dans les poches ?

Bref dans les 2 cas ceci constitue une vrai menace pour le métier de développeur qui risque de disparaître ou bien d'être réservé que aux meilleurs.

[ptah35]

Prétendre que les différents métiers de l'industrie du logiciel forment une hiérarchie, au sommet de laquelle se trouve celui de développeur est absurde. Bien sûr qu'un développeur doit avoir quelques compétence s'agissant des bases de données et des SGBD et qu'il doit être capable de produire des tests pour son code, mais les compétences nécessaires pour utiliser (ou même modifier une base de données) ne constituent pas, et de loin, l'ensemble des compétences nécessaires à l'administration de plusieurs dizaines de base de données par un DBA. De la même manière, peu de développeurs ont les compétences requises pour la mise en place d'une forge logicielle complexe, choisir une politique adéquate et la renforcer cette politique par tous les moyens à disposition. Tous doit avoir quelques compétences dans les autres métiers, ces compétences permettent à chacun de tenir compte des contraintes des autres et de rendre ainsi le processus plus fluide.

[azias]

J'ajouterais que le danger n'est pas seulement côté développeur mais aussi du côté de l'entreprise. Je me suis retrouvé dans une situation dans laquelle je me suis retrouvé à, pour ainsi dire, tout faire (j'ai même été l'unique salarié pendant plusieurs mois). Au bout d'un moment: ras le bol de faire le travail de deux ou trois personnes et d'être payé comme un débutant. Je suis parti et l'entreprise n'a pas survécu à mon départ.

Même en imaginant que le salarié le supporte bien, quand on concentre trop de compétences et de responsabilités sur une seule personne, l'entreprise se met elle-même en danger. Je crois qu'on a déjà tous vu des développeurs (et pas seulement des développeurs) agréger volontairement un maximum de responsabilités sur eux-même et écrire le minimum de documentation (voire rien du tout) pour se rendre quasiment invirable. C'est pourtant généralement ceux-là dont on voudrait se débarrasser.

[epsilon68]

Je crois que de toutes facons on n'a plus le choix, et puis c'est ce qui peut nous differencier des indiens et de l'offshore en general. Ils sont souvent dédiés pour une seule tâche, ce qui fait qu'ils sont un peu perdu quand il faut maitriser plusieurs techno...

Maintenant, je suis d'accord, a force de tout faire, on finit par s'y perdre. Aussi on se rend compte que les autres ne font pas forcement autant et c'est assez frustrant. On se voit tout le temps debordé et finalement les autres ont la vie plus cool.

D'autre part, le plus gros probleme c'est pour les vacances. Aucun probleme pour le soi-disant chef de projet, mais pour nous, ce n'est jamais le bon moment, on est devenu une ressource critique... Grrr

[Invité]

Maintenant, je suis d'accord, a force de tout faire, on finit par s'y perdre. Aussi on se rend compte que les autres ne font pas forcement autant et c'est assez frustrant. On se voit tout le temps debordé et finalement les autres ont la vie plus cool.

D'autre part, le plus gros probleme c'est pour les vacances. Aucun probleme pour le soi-disant chef de projet, mais pour nous, ce n'est jamais le bon moment, on est devenu une ressource critique... Grrr

Oui, j'ai remarqué cela aussi, les chefs de projets sont souvent en vacances car quand j'ai un entretient pour effectuer un stage, souvent, je n'ai jamais de réponse parce que le chef ou bien un tel est injoignable, bref, c'est assez frustrant, autant laisser l'entreprise faire faillite dans se cas là et essayer de créer sa propre boîte là dans un domaine ou il y a de la demande bien sûr. (L'informatique est un métier très vaste et le métier de développeur ne constitue en aucun cas le sommet d'une hiérarchie, loin de là)

Donc c'est aussi au développeur salarié de se rendre compte que ce n'est pas à lui de faire tout le travail pour avoir le salaire d'une seule personne,

Ça ne sert à rien de s'acharner je préférera encore être viré que de devoir me taper tout le travail à moins seul pour un salaire, médiocre, faut pas avoir peur de s'affirmer.

[Cyrilange]

L'avenir du développement est dans le développeur indépendant. Le contrôle qualité, et autres requis, seront gérés par les stores et les plateformes de Cloud.

[Saverok]

L'avenir du développement est dans le développeur indépendant. Le contrôle qualité, et autres requis, seront gérés par les stores et les plateformes de Cloud.

Un développeur indépendant est développeur libéral qui travaille pour des clients (comme un presta d'une SSII sauf qu'on zappe la couche SSII)
Autrement dit, si le client veut du devOps, le développeur libéral fera tout car il a besoin de son cachet pour vivre...

Et puis, côté cloud, il faut bien également des développeurs.
Si l'entreprise qui gère le cloud veut des dev fullstack, ça sera des développeurs fullstack qui administreront la plateforme de cloud...


Autrement dit, ce qu'il faut changer, c'est la mentalité des entreprises qui cherchent à faire de la compression de personnel à outrance, y compris sur le SI.

[devyreham]

En solo j'essaies de standardiser mon architecture de manière justement à ne pas être indispensable. Cependant le management ne m'en laisse pas souvent le temps. Il faut à chaque fois justifier le temps passé. Pourquoi on sépare tel truc de tel chose etc... Apparement dans leurs têtes c'est du "fullStack" aussi pour les produits.

Il faut garder en tête qu'ils n'y connaissent rien, y compris et surtout ceux qui ont un background technique. Les technologies ont changé trop rapidement en 20 ans.
Par exemple, un tas de Design Pattern communs sont intégrés dans les Frameworks.

"Peux tu tester si l'objet a changé et faire l'action seulement si y a un changement?"
"euh c'est deja inclu dans le comportement de base.."

parce qu'evidemment dans les anciens langages il fallait le faire explicitement.
Plus gobalement ils imaginent des problèmes au mauvais endroits. D'où le fullStack car ils pensent ainsi maîtriser finement les interactions "que ca pourrait pas marcher à plusieurs".

Solutions:
- de la pédagogie (toujours répéter la même chose)
- être rigoureux et ne pas tomber dans les raccourcis sous la pression.
- plannifier sa carrière sur le long terme (en gros on s'en fout si la boite actuelle se plante)

[epsilon68]

ho punaise oui, ceux qui ont soi-disant un background technique sont surement les pires.