GRATUIT

Vos offres d'emploi informatique

Développeurs, chefs de projets, ingénieurs, informaticiens
Postez gratuitement vos offres d'emploi ici visibles par 4 000 000 de visiteurs uniques par mois

emploi.developpez.com

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

Le , par Arsene Newman, Expert éminent sénior
« 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 ?


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


 Poster une réponse

Avatar de benjani13 benjani13 - Membre expérimenté http://www.developpez.com
le 01/08/2014 à 0:37
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.
Avatar de deusyss deusyss - Rédacteur/Modérateur http://www.developpez.com
le 01/08/2014 à 7:39
Citation Envoyé par benjani13  Voir le message
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.
Avatar de grunk grunk - Modérateur http://www.developpez.com
le 01/08/2014 à 8:33
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 ...
Avatar de pcaboche pcaboche - Rédacteur http://www.developpez.com
le 01/08/2014 à 8:46
Ç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...
Avatar de spidetra spidetra - Membre averti http://www.developpez.com
le 01/08/2014 à 9:28
Avatar de Grimly Grimly - Membre actif http://www.developpez.com
le 01/08/2014 à 11:43
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.
Avatar de TidiusFF TidiusFF - Nouveau membre du Club http://www.developpez.com
le 01/08/2014 à 11:52
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.
Avatar de Gugelhupf Gugelhupf - Modérateur http://www.developpez.com
le 01/08/2014 à 12:29
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.
Avatar de DonQuiche DonQuiche - Expert confirmé http://www.developpez.com
le 01/08/2014 à 13:40
Citation Envoyé par deusyss  Voir le message
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.
Avatar de spidetra spidetra - Membre averti http://www.developpez.com
le 01/08/2014 à 13:42
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".
Offres d'emploi IT
Analyste développeur
LITOO - Ile de France - Bois-Colombes (92270)
CDI Mantes la Jolie 78 Ingenieur dev LABVIEW confirmé
SETRI - Ile de France - Mantes la Jolie 78200
Consultant bi datastage (h/f)
Atos Technology Services - Ile de France - Bezons (95870)

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