Discussion :

[Amine Horseman]

Devrions-nous écrire moins de code et plus de blogs ?
Selon plusieurs développeurs, le code n'est pas notre principale fonction

Laura Klein, auteur du livre UX for Lean Startups avait écrit une lettre sur Medium destinée « aux Ingénieurs qui ne se soucient pas réellement de leurs clients » dans laquelle elle explique son point de vue concernant l'écriture du code dans le métier de développeur.

« Je sais, vous pensez que vous avez été embauché pour écrire du code. En fait, votre entretien d'embauche entier était centré autour de la façon dont vous pourriez écrire du code, et je suis sûr que vous le faites très bien. Mais ce n'est pas votre travail ». Elle rappelle ensuite que les clients ne sont pas tous équipés des derniers MacBook Air avec un écran haute résolution. « Beaucoup d'entre eux ont une version d'Internet Explorer vielle de quatre ans sur d'anciens PC, donc parfois, les choses que vous construisez ne fonctionnent pas bien sur leurs machines [...] alors s'il vous plaît assurez-vous que le code que vous avez écrit s'exécute dans un nombre raisonnable d'environnements ». Pour cela, elle déclare qu'il est nécessaire de tester son code en production et non pas seulement en local. Aussi, ce code devrait couvrir tous les scénarios d'utilisation possibles même en cas d'erreur et d'absence de données, ou lorsque par exemple « le client utilise le bouton retour ou crée deux comptes par erreur ».

Un autre point important selon elle est le fait de pouvoir mesurer la qualité du travail effectué, « si vous vous attendez que le code écrit va améliorer l'engagement des utilisateurs, alors vous devez avoir un moyen de savoir si vous avez réussi ou non ». Et elle conclut en précisant que ceci s'applique aussi aux Designers, aux Managers et même au directeur de l'entreprise puisqu'ils ont tous un point commun : améliorer le produit pour les clients.

Toutefois, Mike Grouchy aborde le sujet de l'écriture du code sous un autre angle. En effet, pour ce blogueur et contributeur à pycoders : un développeur doit écrire le moins de code possible. « Regardez vos outils et vos environnements, tous essaient de vous faire écrire moins de code », avait-il déclaré dans un billet de blog sur Medium. « Votre travail est de penser, il consiste à réfléchir sur le problème à portée de main, concevoir une solution élégante et puis convertir cette solution en logiciel », déclare Mike, avant de rappeler que l’écriture du code n’est qu’une des nombreuses étapes de la création de logiciels.

Aussi, un autre blogueur sur Medium avait écrit en décembre dernier que les ingénieurs en informatique devraient écrire plus souvent, non pas du code, mais plutôt écrire des blogs et des essais. Il attire notre attention sur les similitudes qui existent entre ces deux disciplines : les deux commencent avec une idée et une page vierge, on remplit cette page au fur et à mesure tout en suivant une certaine structure, on revient ensuite sur telle ou telle partie pour la modifier ou la corriger, jusqu'à ce qu'on obtienne un produit final destiné à un public bien ciblé. « Ce produit est une séquence d'instructions logiques groupées en unités modulaires, que ce soit des fonctions ou des paragraphes ». Aussi, il rappelle qu'un bon texte comme un bon programme doit être clair et concis.

« Les ingénieurs logiciels doivent écrire parce que notre métier est devenu de plus en plus collaboratif. Les projets open source invitent à une participation mondiale, tandis que les produits de l'industrie exigent souvent une armée d'ingénieurs. Bien écrire, que ce soit dans un commentaire GitHub, une révision de code, ou dans la documentation technique, facilite la communication dans les projets, et permettent d'aller de l'avant ». Il explique aussi que même dans les projets qui ne nécessitent pas de communication cela reste important en citant à titre d'exemple l'écriture de blogs, de tutoriels et de livres sur l'informatique qui sont plus faciles à aborder pour les débutants que la documentation technique.

Source : Article de Laura Klein, Article de Mike Grouchy, Article de Shubhro Saha

Et vous ?

Partagez-vous les avis de ces blogueurs ?

Pensez-vous que les développeurs devraient écrire moins de code et plus de blogs/essais/livres ?

[kolodz]

Les avis de ces 3 blogueurs :

No matter what our job titles, our jobs are all the same — to make the product better for our users. Every day. So let’s do that.
Thank you,

Your Product Manager

Il a raison. Il semble qu'il ne soit pas "manageur produit" pour rien...

So, whats the lesson here? Most importantly I think the lesson here is that code is a means to an end, it’s that unavoidable thing that you generate in the process of solving problems with software. So think more, refactor more, remove some old code and write less new code, do yourself a favour and start this today.

Donc, on repense le code un patchwork. C'est du bon sens... En particulier sur le long termes.

Writing offers the same sense of impact that motivates an engineer to write software. Combine this with how it promotes skills useful in software engineering and facilitates collaboration, then suddenly writing appears to be a worthwhile activity.

J'ai une vision un peu plus généraliste sur la question où l'art d'écrire pour être lu par tous devient une nécessité. Non seulement pour les spécialistes de l'informatique, mais par tout le monde.
Un de mes billets en parle indirectement :
Le cycle de croissance de l'internaute et le cycle de croissance du développeur
La source que j'utilise dans ce billet parle, justement de l'intérêt générale à éduquer les jeunes(et moins jeunes) à écrire pour être lu et structurer leur propos.

Cordialement,
Patrick Kolodziejczyk.

[yahiko]

A en juger par les citations de cette Laura Klein, je lui décernerais volontiers la palme de l'enfonçage de portes ouvertes...

[Jarodd]

Pour cela, elle déclare qu'il est nécessaire de tester son code en production et non pas seulement en local.

Tester en production, non mais sérieusement

« s'il vous plaît assurez-vous que le code que vous avez écrit s'exécute dans un nombre raisonnable d'environnements »

Tester sur plusieurs environnements, ça c'est une idée de génie. Merci Captain Obvious, personne n'y avait encore pensé !

« Beaucoup d'entre eux ont une version d'Internet Explorer vielle de quatre ans sur d'anciens PC, donc parfois, les choses que vous construisez ne fonctionnent pas bien sur leurs machines [...] alors s'il vous plaît assurez-vous que le code que vous avez écrit s'exécute dans un nombre raisonnable d'environnements »

Merci pour cette nouvelle vérité. Mais apparemment nous n'avons pas les mêmes clients. Pourquoi j'irai me casser le fondement à assurer une compatibilité IE7 si le client n'en veut pas ? C'est quoi ce conseil moisi, il y aurait donc une seule règle pour les gouverner tous ?

« Votre travail est de penser, il consiste à réfléchir sur le problème à portée de main, concevoir une solution élégante et puis convertir cette solution en logiciel »

Oui, donc au final il faut quand même écrire du code...

Cette personne travaille chez Lapeyre pour enfoncer autant de portes ouvertes ?

Allez, next

[Invité]

Des portes ouvertes surement, malheureusement dans les faits les codes non testés correctement et passés en production sont encore légions

[nanopowered]

Vérifier la version du navigateur et tester son code en production !
Ce qui recommande cela sont soit des idiots, soit prennent les autres développeurs pour des idiots non ?
Ecrire des blogs au lieu de coder ?
Je ne vois aucun argument pour appuyer ce point de vue. Mais si je fais ca, ma mission va rapidement se raccourcir ...
Un article sans intérêt, comme trop souvent.

[mothsART]

Comme souvent, les idées proposés sont intéressantes mais sont soit mal formulé soit mal traduites...
Bien entendu, quand on parle de tester en "production", l'idée est bien "en condition de production" :
ex: si c'est une app web, tester dans un environnement isolé, dans un mode DEBUG=false, avec un "vrai" serveur http (apache, nginx), avec les contraintes de navigateurs du client etc.

Faut être honnête, le dev ne supporte pas (plus) les tâches répétitives et ses tests sont souvent limités par le temps, la motivation, ses raccourcis, sa compréhension générale etc.
Si à chaque modification, il doit remplir 3 formulaires et effectuer 10 clics, on peut sensiblement s'attendre à ce que la phase de test soit médiocre.

J'aime l'idée de communiquer : le dev-blog peut être un moyen.
Je vois trop d'impact direct lié à une mauvaise communication : mauvais choix techniques qu'on va se coltiner pour les 10 années à venir.
Un développeur doit aussi savoir écouter, proposer, convaincre, argumenter, anticiper...

Participer à des projets open-source via github ou autre permet, à mon sens, de se détacher du côté émotionnel.
Je m'explique : dans une boite, il y a souvent des clivages lié au relationnel.
Si on a tendance à ne pas apprécié quelqu'un, notre communication et choix techniques seront forcément altérés par ce soucis.
On fait des amalgames : c'est pas parce que quelqu'un est un parfait connard qu'il a forcément des idées et directions mauvaises.
L'open-source apprend l'humilité, la méritocratie etc.

Le blog permet de faire des choses sans être la tête dans le guidon, de répondre aux questions du pourquoi, comment, quel évolution, quel cadre/limite etc. qu'une doc technique ne doit pas aborder.

Aussi, beaucoup de dev ont perdu la relation direct avec le client final : du coup, il y a un vrai décallage.
Se forcer à la communication aide à résorber cet écart.

Je comprend "écrire moins de code ..." comme :
* valider son code par des tests : automatisés ou non
* refactoring régulier (les besoins du projet peuvent évoluer, notre compréhension aussi)
* chaque ligne écrite est de la responsabilité du dev... plus il en écrit et plus ses épaules s'élargissent
* résoudre un bug ne veut pas dire suivre le traceback jusqu'à la ligne incriminé et le résoudre mais bien avoir une compréhension "générale" du code impacté.
* revue de code
* écrire de la doc (c'est au dev de le faire même si son écriture est approximative... il s'améliorera)
* écrire le pourquoi de notre code à un instant t
* écrire du code qui sera vraiment utilisé (y'a combien de softs qui ont des fonctionnalités que personne n'utilise)
* déterminer qu'est ce qui a vraiment de la valeur et ce qui en a moins. (les tickets d'un bugtracker ne seront jamais résolus à 100% : il faut donc impérativement traiter les choses par priorité)
* intégrer des libs externes
* architecturer = faire dans l'ordre.

Ca oblige au dev de travailler par cycles de validation.

[Logicielz]

SVP mettez les liens hypertextes dans une couleur différente

[clementmarcotte]

Bonjour,

Sans avoir tout lu, cela me semble être la Xième version de l'éternelle question : Vaut-il mieux enseigner comment le faire (ce qui en passant est supposé être l'unique (ou presque) but des forums) ou le faire soi-même ?

Même, si, ici-même, les règles disent que les forums, ne fournissent pas de code clef-en-main; on voit quand même passer énormément de code clef-en-main.

Savoir que cela peut, possiblement prendre, disons, le double du temps, pour montrer comment le faire plutôt que de le faire soi-même; cela peut être tentant de le faire soi-même. Il faut programmer pour apprendre à programmer. On peut apprendre sur le tas à partir des conseils des pairs, on peut apprendre des exemples disponibles un peu partout, on peut apprendre des tutoriels, on peu apprendre des livres ou aller à l'école.

D'un autre côté, la diffusion des connaissances est primordiale. Ceci dit, qui, et comment, doit diffuser cette connaissance. Est-ce que le meilleur développeur du monde doit écrire lui-même un blogue sur son art; s'il a de la misère à aligner deux phrases sans faute ou qu'il a des difficultés à structurer sa pensée et à bien expliquer ? Il n'y a pas de réponse décisive, cela dépend beaucoup plus de la compétence, prise dans un sens très large, et des intérêts de l'individu. De la même façon, qu'on ne demandera pas à un psychiatre d'enseigner l'orthopédie.

Finalement, cela me fait penser à un vieille blague (ou peut-être un vieux cliché) : "Il a appris à nager par correspondance."

[RyzenOC]

Un développeur ne fait plus que du code depuis très longtemps, aujourd'hui il fait le cahier des charges par exemple.

[Laurent 1973]

Pour cela, elle déclare qu'il est nécessaire de tester son code en production et non pas seulement en local.

Moi, je comprend cette phrase plutôt dans l'idée de tester dans des environnements similaire à nos utilisateurs finaux (pas réellement en production).
Les machines développeurs ne sont pas des environnement réalises.

J'encourage aussi les développeurs à faire des visites chez leurs utilisateurs pour voir comment ils utilisent l'outil.
J'ai eu à le faire 2 fois dans un contexte d'un logiciel de pilotage d'instrument d'analyse pour l'industrie:

1. Dans un labo d'une raffinerie, les PCs étaient coincés entre 2 appareils d'analyse sur des grandes paillasses de chimie avec à peine la place pour le clavier et la souris, les opérateurs utilisant le logiciel debout.
   J'ai alors compris qu'il fallait une interface très simple, privilégier les boutons de raccourcis type F1 ... F12 et d'avoir une interface graphique qui tiens sur du 15 pouces (800x600)
2. Dans un labo de contrôle de production, le client nous laissait le serveur 2h pour: faire les sauvegardes, appliquer la mise à jours, tester la nouvelle version et revenir en arrière si cela n'était pas satisfaisant. Chaque heure d’interruption du labo coûtait plusieurs milliers d'euro au client.
   Dans ce cas, les procédures de mise en production et de validation doivent être hyper soignées, on n'a pas le temps et le droit d'hésiter dans cette situation.

Donc, en effet, les développeurs ne sont pas fait pour coder bêtement mais pour participer au développement d'un produit logiciel dont des utilisateurs ont des besoins et des contraintes parfois critiques.
Il est très important que l'on fasse évoluer nos métiers vers plus de "pourquoi" que du "comment" on réalise nos produits informatiques.

Pour cela, il faut être à l'écoute de nos utilisateurs.
L'utilisation d'un blog est une idée à creuser.
Mais dans d'autre cas, il faudra plutôt mettre en place des rencontres physiques entre utilisateurs et développeurs.
Soyons ingénieux pour imaginer comment répondre à cette mutation de nos métiers.

[Luckyluke34]

Ces billets de blog n'ont rien à voir entre eux.

• Le premier, c'est de la provoc' ("Your job is not to write code"... aussi crédible que dire à un boulanger que son métier n'est pas de faire du pain) pour attirer l'attention sur des aspects souvent délaissés du cycle de réalisation d'une application, comme tester aux limites, déployer et tester sur plusieurs environnements/configurations, etc.

• Le but du deuxième est de distinguer qualité et quantité, réflexion et pissage de code, il dit lui-même que ce n'est pas tout à fait vrai qu'il faut écrire moins de code :

When I said earlier that your job was to write less code, I was fibbing a little bit. Really your job is to think

• Le 3ème ne dit absolument rien sur la quantité de code à taper, il fait un parallèle entre l'écriture "littéraire" et le développement. Il préconise d'écrire plus de billets de blog, de documentation, etc. ce qui va affûter nos compétences rédactionnelles et notre capacité à organiser un écrit, ce qui est aussi utile pour programmer.

Je pense personnellement qu'il faudrait écrire non pas moins mais plus de code, peut-être pas dans un même projet mais de manière générale. C'est en s'entraînant qu'on s'améliore, donc tout ce qui est projet perso/open source, hackathon, veille techno sur des langages, etc. est bénéfique. Je me méfie aussi des gros frameworks "all inclusive" qui certes permettent d'écrire moins de lignes de code mais nous assistent et nous prennent par la main jusqu'à parfois nous faire totalement oublier qu'il y a mille façons de résoudre un problème en programmation, ce qui fait perdre sur le long terme une certaine autonomie et une capacité d'adaptation.

[gangsoleil]

Mouais...

• Write less code --> Keep it short and simple. Rien de neuf.
• Ecrire en plus de faire du code, car cela requiert les mêmes compétences : ce n'est pas parce qu'on a les compétences pour écrire qu'on a quelque chose à dire. Si je parlais de mon boulot, je pense que mon employeur, qui ne met pas son code en open-source, ne serait pas content. Et si c'est pour ouvrir un blog sur les chats, autant ne pas le faire.
• Your job is not to write code --> il est vrai que le boulot doit être avant tout d'améliorer le logiciel dans le sens du client, comme elle le dit, mais le reste n'est que lapalissades

Pour moi, ces trois personnes s'adressent avant tout à des gens qui écrivent du code, mais qui n'ont pas une réelle formation de développeurs, c'est à dire des gens à qui il manque forcément des bases ; et dans ce contexte, alors oui, il peut être utile de rappeler certaines bases.

[Zirak]

Moi, je comprend cette phrase plutôt dans l'idée de tester dans des environnements similaire à nos utilisateurs finaux (pas réellement en production).
Les machines développeurs ne sont pas des environnement réalises.

J'encourage aussi les développeurs à faire des visites chez leurs utilisateurs pour voir comment ils utilisent l'outil.
J'ai eu à le faire 2 fois dans un contexte d'un logiciel de pilotage d'instrument d'analyse pour l'industrie:

1. Dans un labo d'une raffinerie, les PCs étaient coincés entre 2 appareils d'analyse sur des grandes paillasses de chimie avec à peine la place pour le clavier et la souris, les opérateurs utilisant le logiciel debout.
   J'ai alors compris qu'il fallait une interface très simple, privilégier les boutons de raccourcis type F1 ... F12 et d'avoir une interface graphique qui tiens sur du 15 pouces (800x600)
2. Dans un labo de contrôle de production, le client nous laissait le serveur 2h pour: faire les sauvegardes, appliquer la mise à jours, tester la nouvelle version et revenir en arrière si cela n'était pas satisfaisant. Chaque heure d’interruption du labo coûtait plusieurs milliers d'euro au client.
   Dans ce cas, les procédures de mise en production et de validation doivent être hyper soignées, on n'a pas le temps et le droit d'hésiter dans cette situation.

Donc, en effet, les développeurs ne sont pas fait pour coder bêtement mais pour participer au développement d'un produit logiciel dont des utilisateurs ont des besoins et des contraintes parfois critiques.
Il est très important que l'on fasse évoluer nos métiers vers plus de "pourquoi" que du "comment" on réalise nos produits informatiques.

Pour cela, il faut être à l'écoute de nos utilisateurs.
L'utilisation d'un blog est une idée à creuser.
Mais dans d'autre cas, il faudra plutôt mettre en place des rencontres physiques entre utilisateurs et développeurs.
Soyons ingénieux pour imaginer comment répondre à cette mutation de nos métiers.

Je suis d'accord avec ça, bien qu'il ne faut pas oublier également, que suivant la structure de la société, le développeur n'est pas forcément en contact avec l'utilisateur / le client et qu'il ne fait que suivre des spécifs / un cahier des charges.

La plupart des devs (malgré le cliché du ronchon qui code tout seul dans son garage), aimeraient bien être plus proche des utilisateurs métiers et essayer de coller au plus proche de leurs besoins, c'est bien pour cela, (enfin c'est mon impression), qu'avant on était "analyste" - programmeur / développeur, alors que maintenant, on a des devs + AMOA + MOE + etc etc, le même boulot s'étant dilué en plusieurs pour des soucis "d'efficacité" et de "rentabilité" (et de devoir justifier le salaire de certains ).


Quant à la tenu d'un blog, pour des développements perso, pourquoi pas, après niveau pro, encore faut-il avoir le temps... Quand il y a déjà moins de jours vendus au client que de jours nécessaires à la réalisation du projet, on a pas le temps d'aller écrire des pavés sur le web pour expliquer le pourquoi du comment, à peine le projet est-il fini qu'il faut enchainer sur le suivant...

[el_slapper]

(.../...)
La plupart des devs (malgré le cliché du ronchon qui code tout seul dans son garage), aimeraient bien être plus proche des utilisateurs métiers et essayer de coller au plus proche de leurs besoins, c'est bien pour cela, (enfin c'est mon impression), qu'avant on était "analyste" - programmeur / développeur, alors que maintenant, on a des devs + AMOA + MOE + etc etc, le même boulot s'étant dilué en plusieurs pour des soucis "d'efficacité" et de "rentabilité" (et de devoir justifier le salaire de certains ).(.../...)

Je vais partir de là et m'éloigner du sujet, mais difficile de ne pas te donner raison.

Une des racines de ce problème, je crois, c'est le manque de formation industrielle des managers. J'ai un diplôme d'ingénieur, un vrai, je suis formé pour concevoir des moules de tableau de bord de voiture, pas pour concevoir des tests automatiques de logiciels médicaux. Pendant ma formation, on m'a matraqué avec "le fordisme, c'est obsolète, c'est de la merde, fuyez-le". C'était il y a 20 ans, et ça doit toujours être comme ça(enfin j'espère).

Pourtant, le mythe de la division du travail persiste de manière majeure parmi nos managers. Parce qu'au final, ils n'ont pas eu ma cure de désensibilisation au fordisme et au taylorisme. Le vieux Ford lui-même disait qu'il n'avait poussé la division du travail à l'absurde que parce qu'il avait 50 langues dans l'atelier et un turnover annuel de 480%. Dans toute situation plus stable, cela aurait été aberrant à ses yeux. Mais lui, il avait besoin d'un travailleur opérationnel en 1 heure parce qu'il n'allait pas rester longtemps. Nos livres d'histoire sont à ce titre trompeurs. Ils présentent comme ultime ce qui n'a été qu'un accident de l'histoire. Et nos managers baignent dans cette culture erronée. Et donc, dans leur esprit, découper le travail, c'est bieeeeeeeeeeeeeeeennnnnn.

C'est d'autant mieux dans leur esprit que ça facilite le WBS, panacée du management de projet tel qu'il est enseigné de nos jours. Qui est un outil d'ailleurs utile, mais qui ne devrait pas être l'alpha et l'oméga du management comme il l'est souvent. Donc, plutôt que de comprendre le boulot de leur subordonnés(tâche difficile, et don ont leur à appris qu'elle était difficile), ils préfèrent(et après leur lavage de cerveau façon MBA, c'est inévitable) de découper le travail en cases ridiculement petites, pour être surs de tout maitriser.

Ce qu'on ne leur a pas appris, c'est que le développement informatique, c'est une tâche fluide, avec d'innombrables dépendances invisibles, avec une exigence forte de savoir-faire, et un poids de la communication très fort. Si un découpage minimal en WBS est généralement utile(toi tu fais la prescription, toi tu fais les urgences, toi tu fais le bloc, et toi tu testes), quand on pousse trop loin la logique, ça devient vite n'importe quoi. Les doctrines industrielles modernes poussent à donner plus de pouvoir aux ouvriers(des gens qui ont parfois bac-2 mais qui connaissent leur boulot) et font la fortune de groupes comme Mercedes. Le gars chargé de monter les rétroviseurs peut proposer toute amélioration concernant son poste, et les ingénieurs, généralement, suivent(ils veulent leur prime, eux aussi). C'est ça, l'industrie moderne.

Et, en informatique grands comptes, le bac+5 recruté assez cher a moins de pouvoir que le gars qui monte les rétroviseurs chez Mercedes. Il est considéré comme un bête manœuvre du XIXème siècle, un ignare analphabète qui doit être opérationnel en 1 heure, et donc on va le cantonner à un rôle ridicule. J'ai vu un client(qui m'a jeté, Dieu merci), qui avait :
_un intervenant qui écrivait l'expression de besoins.
_un autre qui faisait le cahier des charges.
_un autre qui se fadait les specs fonctionnelles générales.
_un autre qui pondait les specs fonctionnelles détaillées.
_un expert technique(poste pour lequel ma SSII me positionnait) qui se farcissait les specs techniques générales, et faisait le suivi du prestataire, et les tests.
_un prestataire hors-site qui imaginait les specs techniques détaillées.
_un autre prestataire hors-site qui codait
_et derrière, je ne sais même pas.

donc, pas loin d'une dizaine d'intervenants. C'est évidemment une catastrophe - toutes les infos sont perdues en permanence, et personne ne comprend ce qu'il faut faire. Mais c'est logique - le management a appris que son métier était la science du contrôle. Et découper les équipes, ça permet d'empêcher ces connards de grouillots de prendre des initiatives non approuvées.

[yahiko]

Il faudrait surtout que les décisionnaires (certains DSI entre autres) intègrent que le développement informatique n'est pas une activité industrielle mais tout autant un "art".

La division du travail est à priori une bonne chose (aspect humains mis à part) en terme d'efficacité lors qu'on a à faire à des tâches déjà maîtrisées, reproductibles, duplicables.

Or, de l'analyse des besoins jusqu'à la transcription en code (sans oublier tout ce qui est intégration, paramétrages et tuning) ce n'est pas la même chose que de fabriquer des Ford T tout en noir à la chaîne. Dans le développement, il y a une part de "R&D" qui est très mal comprise dans une entreprise utilisatrice.

D'où les nombreux clashs entre ces sociétés clientes et les prestataires.
D'où les débats stériles sur le cahier des charges lorsqu'il s'agit de savoir si c'est l'un qui l'a mal rédigé ou si c'est l'autre qui l'a mal interprété... :/

[Galdon]

Je n'ai réussi à lire au premier degré que les deux premières phrases. C'est magique, Laura Klein défonce les portes ouvertes avec autant de classe qu'un quarterback dopé aux stéroïdes le soir de la finale du superbowl au Michigan Stadium !

[SylvainPV]

Des codeurs devraient écrire plus de blogs, et des blogueurs devraient écrire plus de code... c'est l'équilibre entre théorie et pratique. Pour ma part je compte faire les deux

[Mat.M]

Aussi, un autre blogueur sur Medium avait écrit en décembre dernier que les ingénieurs en informatique devraient écrire plus souvent, non pas du code, mais plutôt écrire des blogs et des essais. Il attire notre attention sur les similitudes qui existent entre ces deux disciplines : les deux commencent avec une idée et une page vierge, on remplit cette page au fur et à mesure tout en suivant une certaine structure, on revient ensuite sur telle ou telle partie pour la modifier ou la corriger, jusqu'à ce qu'on obtienne un produit final destiné à un public bien ciblé. « Ce produit est une séquence d'instructions logiques groupées en unités modulaires, que ce soit des fonctions ou des paragraphes ». Aussi, il rappelle qu'un bon texte comme un bon programme doit être clair et concis.

c'est discutable....écrire du code c'est en vue de réaliser un projet logiciel informatique donc c'est en majorité du "fonctionnel".
J'écris du code pour faire une requête SQL sur les clients dont le contrat est arrivé à échéance à une date particuliére.
La narration et l'Ecriture c'est autre chose, on écrit parce qu'on a des idées mais aussi parce qu'on ressent certaines choses, on peut mêler ça avec de la poésie..

Une des racines de ce problème, je crois, c'est le manque de formation industrielle des managers. J'ai un diplôme d'ingénieur, un vrai, je suis formé pour concevoir des moules de tableau de bord de voiture, pas pour concevoir des tests automatiques de logiciels médicaux. Pendant ma formation, on m'a matraqué avec "le fordisme, c'est obsolète, c'est de la merde, fuyez-le". C'était il y a 20 ans, et ça doit toujours être comme ça(enfin j'espère).

c'est curieux , on a pourtant toujours affirmé que le bon côté du fordisme c'était les salaires très élevés qu'on donnait aux salariés de Ford pour qu'ils achétent eux-mêmes les véhicules qu'ils produisaient..bref "faire tourne la boutique"..

Workers are paid higher "living" wages, so they can afford to purchase the products they make. (modified from [3])

Si un découpage minimal en WBS est généralement utile(toi tu fais la prescription, toi tu fais les urgences, toi tu fais le bloc, et toi tu testes), quand on pousse trop loin la logique, ça devient vite n'importe quoi.

c'est exact ; ce qui s'est passé en France c'est qu'on a bêtement voulu copier souvent sur les méthodes de management et les métodes industrielles comme au Japon et aux USA.
Or copier des méthodes industrielles n'est pas toujours pertinent ça c'est comme vouloir appliquer les méthodes AGILE à un projet de développement logiciel alors que c'est pas forcément applicable ( je ne vais pas lancer un débat là-dessus ).
C'est quasiment imbécile de vouloir copier sur les Américains , la taille des entreprises en France n'est pas la même qu'aux USA et surtout le marché n'est pas du tout le même.
Aux USA c'est un marché de masse de 300 milliions de consommateurs, en FRance c''est même pas 70 donc au final c'est plus improductif qu'autre chose..
Mais je vois une raison à l'industrialisation un peu pousée à l'extrême c'est parce qu'il y a la volonté et la nécessité de maitriser les coûts à tout prix...
autrement dit si tu veux industrialiser un projet informatique c'est dans une logique de maitrise de coûts.
Ce qui est dans la réalité difficile à faire puisqu'on ne peut pas industrialiser un projet informatique totalement.

Les doctrines industrielles modernes poussent à donner plus de pouvoir aux ouvriers(des gens qui ont parfois bac-2 mais qui connaissent leur boulot) et font la fortune de groupes comme Mercedes. Le gars chargé de monter les rétroviseurs peut proposer toute amélioration concernant son poste, et les ingénieurs, généralement, suivent(ils veulent leur prime, eux aussi). C'est ça, l'industrie moderne.

pour moi il n'y a pas de doctrines industrielles il n'y a que les lois de l'Economie de marché...

pour prendre l'exemple de Mercedes, la seule doctrine ( comme une majorité d'entreprises anglo-saxonnes) ce qui importe surtout c'est de vendre des voitures à leur client et surtout que les clients soient satisfaits de leurs achats , on peut qualifier cela de pragmatisme allemand..et puis surtout les allemands sont partisans du "deutsche quälitat" donc il n'y pas de doctrines dans ce domaine..
les anglo-saxons ils font tout sauf avoir avoir une vision compliquée des choses : ils fabriquent des produits qui sont conformes aux attentes des consommateurs.

Ensuite pour ce qui est de la condition ouvrière, les allemands privilégient l'apprentissage, la méthode et la progressivité des choses.

J'ai vu un client(qui m'a jeté, Dieu merci), qui avait :
_un intervenant qui écrivait l'expression de besoins.
[..]

merci pour l'anedocte.
Cela s'appelle gérer une armée mexicaine , un système hiérarchique kafkaïen c'est symptomatique des grandes entreprises françaises

[Saverok]

Pensez-vous que les développeurs devraient écrire moins de code et plus de blogs/essais/livres ?

Je trouve cette question assez incongrue et assez mal formulée
Nous faisons un métier complexe où un simple malentendu peut avoir de lourdes conséquences (livraison d'un logiciel non adapté au besoin, par exemple)
Du coup, je pense que de gros efforts doivent être fait pour améliorer la compréhension entre les interlocuteurs et cela ne passe pas uniquement par les développeurs
Cela passe par une bonne expression écrite mais aussi et surtout, orale

En France, sur les spécifications, on a tendance à être trop verbeux
Du coup, cela nuit à la compréhension
Une spéc, ce n'est pas de la littérature. Qu'elle soit fonctionnelle ou technique, une spéc doit être claires, aller droit au but, être explicite.
Autrement dit, on utilise au maximum toute la panoplie UML (y compris le BPM) et on illustre avec des exemples (cas correcte, cas incorrect).

Il y a quelques années, j'ai travaillé sur un projet avec des italiens.
Il s'avère que ces italiens parlaient un peu français et par facilité, j'ai débuté ce projet en français.
Très rapidement, j'ai constaté que le projet dérivait dû à des tas d'incompréhensions diverses des 2 partis.
En poussant l'analyse auto critique, j'ai remarqué, aidé par ma femme, que j'avais tendance à faire des phrases trop longues et à utiliser des mots trop complexes.
Du coup, nous sommes passés à l'anglais et il s'avère qu'avec mon mauvais anglais et leur mauvais anglais également, on se comprenait nettement mieux.
Pour la simple et unique raison qu'on était plus direct.
On ne s'embarrassait plus de mettre les formes pour ne pas froisser les susceptibilités l'autre.
Le but était de faire passer une idée par phrase.
C'était court et percutant, sans ambiguïté.
On faisait plein d'UML et le tout, illustrer par des exemples.
Au final, tout s'est très bien passé et on a même rattrapé le retard pris en début de projet.

Tout ça pour dire que je pense au final un peu l'inverse du sujet du topic.
Les spéc doivent être moins verbeuses et mieux illustrées.