Discussion :

[Arsene Newman]

Le développeur s'éloignerait de plus en plus de son activité principale : le codage !
Voilà le constat amer d'un passionné de programmation

« Laissez-moi juste coder ! » voilà donc le titre du billet d’Andrews Binstock, éditeur en chef de chez Dr.Dobb’s qui estime que le développeur s’éloigne de plus en plus de la tâche la plus basique, la plus ludique et créative de son travail: coder.

Coder est l’activité la plus satisfaisante pour le développeur, car elle lui permet d’exercer sa créativité et son génie, elle permet aussi de lui donner ce sentiment de joie, de satisfaction et d’achèvement si chers à lui, lorsque son application répond parfaitement aux cahiers de charge et aux souhaits du client.

Toutefois, le développeur tend actuellement à s’éloigner de plus en plus de cette activité et pour Benstock : « Ce qui pouvait se rapporter à conduire une simple bicyclette est devenu l’équivalent de voyager avec un avion de ligne avec tout ce que cela implique comme : retards, inspections, limitations sur les choix personnels et des annulations inexpliquées, le tout à un coût sensiblement plus élevé. » Alors où est la joie et la satisfaction dans tout cela ?

Aux premiers abords, Benstock pourrait attribuer cette complexité au développement logiciel moderne, mais une lecture plus raffinée dévoile un autre facteur plus important que celui cité précédemment : « La complexité grandissante dans la maîtrise et la manipulation des outils nécessaires au développement logiciel »

A titre d’exemple, un simple projet de développement d’application mobile nécessite plusieurs outils de nos jours, allant de l’outil de gestion de versions (VCS ou SCM) aux outils dédiés à la traque de bugs en passant par l’IDE, les outils de tests spécifiques à chaque plateforme ou encore ceux utilisés pour vérifier la conformité et l’éligibilité de l’application sur les différents stores mobiles.

Ces différents outils cités précédemment ont beaucoup évolué au fil de la dernière décennie, afin d’atteindre l’apogée « du passage à l’échelle, de l’évolutivité, de la compréhension ou encore de la performance, bref tout sauf la simplicité ».

Il n’est donc pas rare de voir certains outils se doter de leur propre API, ou de leur propre langage qu’il faut apprendre et maîtriser. Un autre exemple fort intéressant serait le cas du VCS Git, ce dernier est un outil très puissant largement utilisé de nos jours et connu pour ses différentes qualités, toutefois « Le problème avec Git, c’est qu’il représente tout un monde à lui seul », sa prise en main initiale peut se faire avec un simple tutoriel, mais si le développeur souhaite utiliser certaines opérations, une compréhension approfondie du VCS est nécessaire, ce qui comporte un surcoût important.

Ainsi, l’expertise du développeur ou encore la direction entreprise importe peu, « la complexité tend à être une réalité insistante prête à emmener le développeur loin de l’activité de base : le codage ».

Alors, que faut-il faire pour y remédier ? Faut-il s’accommoder de cette nouvelle tendance ? Y a-t-il des solutions pour contourner cette situation ? Nul doute que des réponses existent, reste à connaitre si elles sont de réelles solutions, ce qui nous amène au point suivant : ce qui ne devait être qu’un simple constant débouche sur une foule de questions aux réponses incertaines.

Source : Billet d’Andrew Binstock

Et vous ?
Qu’en pensez-vous ?

[benjani13]

Coder est l’activité la plus satisfaisante pour le développeur, car elle lui permet d’exercer sa créativité et son génie, elle permet aussi de lui donner ce sentiment de joie, de satisfaction et d’achèvement si chers à lui, lorsque son application répond parfaitement aux cahiers de charge et à aux souhaits du client.

Je ne suis pas sur que le développeur qui ne fait qu'attendre un cahier des charges, le respecte mot pour mot sans rien dire, et passe au cahier des charges suivants soit très épanouie. Personnellement c'est ce que je fait, et j'aimerais pouvoir avoir un peu plus de poids dans la rédaction du cahier des charges (ou du moins dans son interprétation), pouvoir discuter de la façon dont la fonctionnalité voulu sera implémenté (UI, choix donnés à l’utilisateur, etc). Quand tu fais, parfois, des choses que tu semble pas forcément pertinent pour l'utilisateur (par ce qu'on chef t'a dit de faire ça et pas autre chose), je ne pense pas que ce soit très épanouissant.
De plus, tout dépend de ce que tu code. Quand tu es le petit nouveau à qui on dit "tel équipe à codé de supers algos, tu peux mettre tout ça bout à bout avec une jolie UI?", ce n'est pas très motivant je vous le promet.

A titre d’exemple, un simple projet de développement d’application mobile nécessite plusieurs outils de nos jours, allant de l’outil de gestion de versions (VCS ou SCM) aux outils dédiés à la traque de bugs en passant par l’IDE, les outils de tests spécifiques à chaque plateforme ou encore ceux utilisés pour vérifier la conformité et l’éligibilité de l’application sur les différents stores mobiles.

Je n'ai pas bien compris si c'était une critique ou non. Si c'est le cas, je ne comprend pas pourquoi.

Il n’est donc pas rare de voir certains outils se doter de leur propre API, ou de leur propre langage qu’il faut apprendre et maitriser.

Et le jour ou tu change de boites tu dois prendre en main de nouveaux outils, de nouveau langage, une nouvelle plateforme, de nouveaux framework. C'est le propre du développeur de s'adapter et d'apprendre de nouvelle technos non? Dans ma boite on m'a dit que la monté en compétence prend 2 ans (le temps de prendre en main la plateforme de dev, les framework, etc).

Je finis par une citation de l'article original:

For a long time, I've attributed this frustration to the complexity of today's software. The simple programs of a few hundred lines of C++ long ago disappeared from my experience.

Je pense que cette personne est restée bloquée avec l'image du développeur des années 70/80.

[deusyss]

Je pense que cette personne est restée bloquée avec l'image du développeur des années 70/80.

+1 . Ou alors il se contente de coder des calculatrices .

Sinon, je suis assez d'accord avec le fond de l'article. On nous met tellement de softs dans les roues pour avoir indicateurs, rentabilité, performance, ... qu'au final cela nous plombe plus qu'autre chose. On passe plus de temps à renseigner les logiciels qu'à vraiment coder.

Cela me rappelle un ancien travail, ou le support n'arretais pas de la journée. Un nouveau chef est arrivé et a sorti "on va mettre en place des outils de tickets, de suivi de demande, de statistique, ..." (ça partait d'une bonne volonté). Sauf, que mauvais choix, et chaque technicien passait 10 mn (oui oui, véridique) à remplir un ticket, meme quand la resolution prenait 30s. Au bout de deux mois le chef est arrivé et à dit qu'il n'y avait pas tant de ticket que ça, qu'on lui avait menti, et la moitié de l'équipe à disparu. Et on parle pas des demandes en attente sur post it...

Bref juste pour confirmer que certains logiciels peuvent effectivement appporter un réel plus (les gestionnaires de versions par exemple, ou certaines fonctionnalité ide tel la completion), mais d'autres sont vraiment superflus et ne font que nous plomber.

[grunk]

A titre d’exemple, un simple projet de développement d’application mobile nécessite plusieurs outils de nos jours, allant de l’outil de gestion de versions (VCS ou SCM) aux outils dédiés à la traque de bugs en passant par l’IDE, les outils de tests spécifiques à chaque plateforme ou encore ceux utilisés pour vérifier la conformité et l’éligibilité de l’application sur les différents stores mobiles.

C'est tellement plus cool, de passer sa journée à taper des lignes de code sur une console , sans possibilité de revenir facilement à une version antérieure, sans se rappeler qui s'occupe de tel bug et d'écraser le code de son collègue parce que on à modifié le même code au même moment ...

[Invité]

et d'écraser le code de son collègue parce que on à modifié le même code au même moment ...

Si vous êtes dans ce type de cas, c'est qu'il n'y a aucun de pilote dans l'avion : ça craint pas mal ! C'est même inadmissible !

En gros, le mieux est l'ennemi du bien. Passer plus de temps à apprendre de nouveaux outils plus qu'à développer est frustrant, surtout si les délais deviennent peau de chagrin.

[foetus]

Non le plus gros problème que je vois c'est pour le recrutement et le travail en équipe

Le recrutement: parce que les commerciaux sont friands de termes techniques qu'ils ne connaissent pas: GIT, Versioning, méthode agiles (SCRUM Master), BOOST, ...
Et toi avec ton C.V., si tu n'as jamais travaillé ou juste bidouillé un peu avec ces outils ou ces bibliothèques, tu dois convaincre plus qu'il n'en faut

Le travail en équipe: si tu tombes dans une société où tout est [à peu près] carré avec des experts GIT (ceux qui maintiennent les serveurs), ou d'une bibliothèque par exemple, cela peut devenir très vite un problème si tu ne connais pas plus que cela le(s) techno(s) et surtout si on te laisse pas le temps de l' (les) appréhender correctement

Après, ces technos sont-elles vraiment utiles? Est-ce qu'elles sont bénéfiques ou pas?
Cela dépend justement de comment elles sont installées et utilisées (et accessoirement si elles correspondent bien au développement et qu'elles ne soient pas imposées)
J'ai travaillé dans une société qui faisait du versionning à la main (avec des grosses contraintes sur le code) et en 3 ans il n'y a jamais eu de problème réel.

Mais ce qui est sûr, c'est que certaines permettent de fliquer les développeurs

[DonQuiche]

Sinon, je suis assez d'accord avec le fond de l'article. On nous met tellement de softs dans les roues pour avoir indicateurs, rentabilité, performance, ... qu'au final cela nous plombe plus qu'autre chose. On passe plus de temps à renseigner les logiciels qu'à vraiment coder.

Disons qu'il y a de bonnes et de mauvaises choses qui nous empêchent de coder. On ira difficilement se plaindre du contrôle des sources !

En revanche il y a nombre de pratiques de nature administrative qui pourraient être souvent supprimées : documentation systématisée du code (la doc XML c'est le mal), tests systématisés et extensifs de chaque parcelle du code, tickets systématiques, certains outils d'analyse de code avec 90% de faux positifs et 10% de mouaisbof, refactorings idiots et contre-productifs guidés par une lecture aveugle d'indicateurs de qualité, hooks de dépôt contrôlant l'agencement des interlignes et autres guidelines d'écriture ultra-rigides, etc. Il y a des équipes dans lesquelles 50% de la charge de travail pourrait être virée et, surtout, ce temps mieux utilisé.

Comme partout certains sont obsédés par ces bonnes pratiques (ou soi-disant bonnes pratiques pour certaines) et deviennent des zélotes, jurant leurs grands dieux contre tous les faits que la qualité du projet en est ainsi améliorée (et quand ce n'est pas le cas c'est qu'il faut pousser plus loin). C'est le pouvoir sacré et mystérieux des dashboards, capables de transformer l'individu le plus rationnel qui soit en abruti courant après des loupiotes vertes.

[pcaboche]

Ça c'est le problème de tous ces logiciels sensés nous "simplifier la vie".

Généralement, cela ce passe comme ça :
1. il existe un problème récurrent
2. pour palier à ce problème (ou une partie de ce problème), on invente un outil (ou ensemble d'outils appelés "framework")
3. des gens utilisent cet outil car il répond à leur besoin
4. d'autres gens utilisent cet outil parce qu'ils croient que c'est la panacée
5. l'outil en question amène des problèmes nouveaux (parfois plus durs à résoudre que le problème original...)
6. maintenant il faut à tout prix que les dévelopeurs soient "experts" dans l'outil sensé simplifier la vie


Et encore, ça c'est rien (on demande à un dévelopeur d'utiliser des outils spécifiques à un problème ou un environment, c'est toujours mieux que de réinventer la roue... ).

Le pire, c'est quand on demande à un développeur d'accomplir des tâches qui n'ont absolument rien à voir avec son métier. L'auteur prend comme exemple la publication d'applis sur un store (et toute la partie administrative associée) mais il y a bien pire : par exemple quand on demande au développeur de jouer les commerciaux auprès d'un client potentiel (mais avec en plus tout un tas de formulaires à la con à remplir, sinon ça serait pas drôle... ). Parfois c'est tellement lourdingue que ça en deviendrait presque comique...

[spidetra]

La suite du billet:
http://www.drdobbs.com/architecture-...ding/240168771

[Grimly]

Le titre "Just let me code" et tellement mal choisi ...
Il aurait du choisir "Just let me do my job".

Si une équipe a un administrateur système et que les développeurs doivent mettre la main dans le système, c'est une erreur.
Le rôle de développeur n'est pas de lancer des builds. Si possible, on séparera les parties d'une application en modules qui seront regroupés dans un projet parent, le développeur n'a pas à se charger de ça (sauf si la personne a reçu ce rôle aussi).
De même le système de versionnement n'est pas géré par le développeur, ce dernier ne fait que des commit sur la branche sur laquelle il travail.
Un développeur Java ou .NET ne voudra pas nécessairement développer des interfaces en HTML5.

Après il faut voir la taille de l'équipe. Sur un projet à 2 personnes, et bien désolé pour lui mais il va cumuler 50 rôles et ne codera pas autant qu'il le voudra ou comme il le voudra. Cependant sur un projet à 50+ personnes, si il a le simple rôle de développeur sur des services J2EE et qu'il se charge des builds et déploiement de son module, alors c'est une faute du chef de projet.

[TidiusFF]

Je pense que cette personne est restée bloquée avec l'image du développeur des années 70/80.

+1. Comme quoi même des développeurs, pourtant supposés être un type de personne ouvert aux nouvelles techno, peuvent être conservateurs jusqu'a vouloir régresser.

Comme si bien dit :

C'est tellement plus cool, de passer sa journée à taper des lignes de code sur une console , sans possibilité de revenir facilement à une version antérieure, sans se rappeler qui s'occupe de tel bug et d'écraser le code de son collègue parce que on à modifié le même code au même moment ...

S'il tient tant a être libre de coder comme il en a envie (sans controle de source, ou controles de performances visiblement, probablement du pas très beau), il n'a qu'a lancer son studio... Ah ben non ; il n'a pas envie de le gérer, je présume.

[Gugelhupf]

Aujourd'hui il faut forcément effectuer un suivi, on ne peut pas se permettre de coder comme on le veut, il faut suivre le cahier de charges (en espérant qu'il y en ait un et qu'il soit bien fait), vérifier la qualité du code, mettre en place des tests de non régression et j'en passe, donc ces outils de gestion de projet sont nécessaires même si cela donne l'impression qu'on prend un billet d'avion pour un trajet qu'on pourrait effectuer en vélo.

Je propose quelques solutions pour améliorer le processus :

• Pour chaque catégorie, utiliser un outil : connu, répandu, documenté, à jour. Surtout éviter les frameworks fait maison.
• Donner des formations sur l'outil : installation, utilisation, compréhension des bugs.
• Ne pas négliger dans l'implication du projet : les nouveaux développeurs, les séniors, la MOA.

[spidetra]

Son premier billet est excessif.
Le second billet (Getting Back to Code) nuance le propos.
Ce qu'il remet en cause, ce n'est pas tant les outils eux-mêmes, que leurs tendance naturelle à l'obésité.
Nous avons surement tous en tête un outil que nous apprécions et qui au fil du temps devient une véritable "usine à gaz".

[SurferIX]

Son premier billet est excessif.
Le second billet (Getting Back to Code) nuance le propos.
Ce qu'il remet en cause, ce n'est pas tant les outils eux-mêmes, que leurs tendance naturelle à l'obésité.
Nous avons surement tous en tête un outil que nous apprécions et qui au fil du temps devient une véritable "usine à gaz".

A ma connaissance, il n'y a que vim que tu peux transformer en véritable studio sans qu'il devienne une usine à gaz.

.. des personnes qui n' en n'ont rien à cirer des contraintes auxquelles vous serez confronté, quand bien même vous aurez a cœur de coder le plus proprement possible.L'essentiel "faut que ça marche" et ils empochent le magot le reste on s'en tape même si c'est une usine à gaz...

Voici ce qu'il y a marqué sur les murs de Facebook : "Done is better than perfect"... Véridique, cherchez sur google.
Autrement dit "tant que ça marche et qu'on se fait des thunes sur votre dos, on s'en fout de comment vous le faites".
Imaginez une petite étoile juste après avec l'alinéa en bas de page : "en plus si vous êtes débutant ça tombe bien : on pourra vous exploiter encore plus pour beaucoup moins cher".

Bienvenue dans le monde réel.

[Laurent 1973]

Dans cette réflexion, je me permet de rappeler les 4 valeurs de l'Agilité:

Nous découvrons comment mieux développer des logiciels par la pratique et en aidant les autres à le faire.
Ces expériences nous ont amenés à valoriser :

• Les individus et leurs interactions plus que les processus et les outils
• Des logiciels opérationnels plus qu’une documentation exhaustive
• La collaboration avec les clients plus que la négociation contractuelle
• L’adaptation au changement plus que le suivi d’un plan

Nous reconnaissons la valeur des seconds éléments, mais privilégions les premiers.

=> Voir http://agilemanifesto.org/iso/fr/

Je m'étendrais dans notre cas sur la première valeur.
L'important, ce n'est pas le outil que l'on utilise pour faire notre métier, mais le but et le besoin que l'on en a.

Par exemple, dans le cas d'un outil "bug tracking", l'important n'est pas forcement d'avoir de jolie liste de "bugs" qu'un manageur pourra extraire et classer dans un jolie rapport mensuel.
L'important c'est de répondre à un besoin d'un client ou d'un utilisateur qui nous remonte un défaut ou un nouveau besoin.
Bien prendre en compte cette remarque et la mémoriser.
Autant que faire ce peu, faire en sorte qu'un développeur fasse évoluer le code en conséquence.
Et bien sur, valider la modification.

On peux pour cela utiliser un bug-tracking avec un workflow bien détaillé
On peux aussi noter le problème sur un post-it ou un tableau blanc à la vu de tous avec le titre "à corriger".

Les processus et outils utilisés sont différents, mais le but premier est le même: améliorer la qualité de notre logiciel dans l’intérêt du client.
Le choix d'un tel ou tel, dépendra de la taille du projet et de sa criticité.

Là ou je rejoints la remarque de cette article, c'est que l'on a tendance, dans nos entreprises, à utiliser des outils ou d'appliquer des processus d'organisation en oubliant nos objectifs initiaux: développer des logiciels de qualités.

[landry161]

Quand t'es informaticien dans une boîte avec un chef de projet qui a fait ses études en ressources humaines ne vous attendez pas à ce qu'on vous fasse les yeux doux.
Je dis cela parce vous travaillez pour des personnes qui n' en n'ont rien à cirer des contraintes auxquelles vous serez confronté,quand bien même vous aurez a cœur de coder le plus proprement possible.L'essentiel "faut que ça marche" et ils empochent le magot le reste on s'en tape même si c'est une usine à gaz.
Dommage mais voila le milieu dans lequel nous vivons et ça c'est pas du tout bon

[free07]

Quand t'es informaticien dans une boîte avec un chef de projet qui a fait ses études en ressources humaines ne vous attendez pas à ce qu'on vous fasse les yeux doux.
Je dis cela parce vous travaillez pour des personnes qui n' en n'ont rien à cirer des contraintes auxquelles vous serez confronté,quand bien même vous aurez a cœur de coder le plus proprement possible.L'essentiel "faut que ça marche" et ils empochent le magot le reste on s'en tape même si c'est une usine à gaz.
Dommage mais voila le milieu dans lequel nous vivons et ça c'est pas du tout bon

Ce genre d'attitude ne date pas d'aujourd'hui, cela a toujours existé et c'est pour cette raison que je ne pense pas que l'auteur soit resté bloqué avec l'image du dev des années 70/80, même à cette époque les dangers de créer une usine à gaz étaient aussi présent qu'aujourd'hui.

Il me semble qu'il dénonce surtout la compléxité et la multiplicité de certains outils d'aujourd'hui qui au lieu de simplifier le codage, peut au contraire le rendre plus complexe et plus difficile à maintenir, ce qui peut effectivement amener petit à petit à construire une véritable usine à gaz.

Sans vouloir dire que c'était mieux avant ( bien au contraire ), trouver et utiliser les bons outils et technos pour certains projets peut s'avérer être un choix difficile à faire de nos jours et au regard de la multiplicité des technos mis à notre disposition.
Ce choix est devenu trés important, voir même primordial pour certains projets.

[Bousk]

Faut distinguer les vrais problèmes des faux.

L'utilisation d'un serveur de versionning c'est du tout bon. Tomber dans une équipe de mecs qui jurent que par la ligne de commande pour utiliser Git en est une autre.
En tant que programmeur, il m'est arrivé d'utiliser Git, et ça m'énervait énormément au début, j'avais vite installé un petit truc pour avoir une GUI et pouvoir faire mes commits. Je suis développeur, pas bidouilleur de Git et mettre 5mn pour faire un commit non merci. A ce niveau j'y préfère nettement Mercurial, mais c'est pas le débat.
Mais la gestion du serveur Git ne me revient pas, c'est quelqu'un d'autre qui a ces attributions et compétences.

On dirait qu'il parle du développeur de SSII, en tous cas j'y retrouve des traits, où l'évolution "normale" du développeur c'est chef de projet. Soit bien loin du développement. Et où en plus de tes compétences en développement, on te demandera toujours tout un tas d'extras. Je peux comprendre que ça soit gonflant à la longue.


Les outils doivent rester ce qu'ils sont : des outils, des aides.
S'il faut commencer à développer des compétences particulièrement pointues pour les utiliser, ils deviennent finalement des freins.
Se plaindre du langage/API d'un outil par contre, c'est un peu gros je trouve.

[Jay13mhsc]

lorsque son application répond parfaitement aux cahiers de charge et aux souhaits du client.

Depuis quand une application qui répond parfaitement au cahier des charges (pluriel à l'envers) réponds aussi aux souhaits du client ?
Depuis quand une application qui répond aux souhaits du client est utile ?
(OK, je trolle un peu :p, mais Henry Ford a dit : "si j'avais demandé ce que souhaitaient les gens, ils m'auraient répondu des chevaux plus rapides")

Sinon, non, ça me parait logique.
Le métier de développeur ne consiste pas à s'asseoir, pisser du code, et se barrer.
Son objectif est justement de transformer une idée en incrément logiciel, codé proprement, et (pléonasme) qui marche en prod.
Donc oui, il faut maitriser plein de techniques et d'outils, et oui c'est difficile.
Mais c'est notre TAF, et c'est la vraie vie.

[landry161]

Depuis quand une application qui répond parfaitement au cahier des charges (pluriel à l'envers) réponds aussi aux souhaits du client ?
Depuis quand une application qui répond aux souhaits du client est utile ?
(OK, je trolle un peu :p, mais Henry Ford a dit : "si j'avais demandé ce que souhaitaient les gens, ils m'auraient répondu des chevaux plus rapides")

Sinon, non, ça me parait logique.
Le métier de développeur ne consiste pas à s'asseoir, pisser du code, et se barrer.
Son objectif est justement de transformer une idée en incrément logiciel, codé proprement, et (pléonasme) qui marche en prod.
Donc oui, il faut maitriser plein de techniques et d'outils, et oui c'est difficile.
Mais c'est notre TAF, et c'est la vraie vie.

Cette vie je l'aime énormement