Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

Débats sur le développement - Le Best Of Discussion :

Devrions-nous écrire moins de code et plus de blogs ?


Sujet :

Débats sur le développement - Le Best Of

  1. #1
    Expert éminent sénior

    Homme Profil pro
    Développeur informatique
    Inscrit en
    septembre 2014
    Messages
    194
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Algérie

    Informations professionnelles :
    Activité : Développeur informatique
    Secteur : Enseignement

    Informations forums :
    Inscription : septembre 2014
    Messages : 194
    Points : 12 273
    Points
    12 273
    Par défaut Devrions-nous écrire moins de code et plus de blogs ?
    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 ?

  2. #2
    Modérateur
    Avatar de kolodz
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    avril 2008
    Messages
    2 203
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 32
    Localisation : France, Rhône (Rhône Alpes)

    Informations professionnelles :
    Activité : Ingénieur développement logiciels
    Secteur : High Tech - Produits et services télécom et Internet

    Informations forums :
    Inscription : avril 2008
    Messages : 2 203
    Points : 8 286
    Points
    8 286
    Billets dans le blog
    51
    Par défaut
    Les avis de ces 3 blogueurs :
    Citation Envoyé par Laura Klein
    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...

    Citation Envoyé par Mike Grouchy
    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.

    Citation Envoyé par Shubhro Saha
    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.
    Si une réponse vous a été utile pensez à
    Si vous avez eu la réponse à votre question, marquez votre discussion
    Pensez aux FAQs et aux tutoriels et cours.

  3. #3
    Rédacteur/Modérateur

    Avatar de yahiko
    Homme Profil pro
    Développeur
    Inscrit en
    juillet 2013
    Messages
    1 201
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Alpes Maritimes (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Développeur

    Informations forums :
    Inscription : juillet 2013
    Messages : 1 201
    Points : 7 563
    Points
    7 563
    Billets dans le blog
    43
    Par défaut
    A en juger par les citations de cette Laura Klein, je lui décernerais volontiers la palme de l'enfonçage de portes ouvertes...
    Tutoriels et FAQ TypeScript

  4. #4
    Membre expérimenté
    Avatar de Jarodd
    Profil pro
    Inscrit en
    août 2005
    Messages
    840
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : août 2005
    Messages : 840
    Points : 1 644
    Points
    1 644
    Par défaut
    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

  5. #5
    Membre éprouvé
    Homme Profil pro
    Noob
    Inscrit en
    octobre 2009
    Messages
    344
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Nouvelle-Zélande

    Informations professionnelles :
    Activité : Noob

    Informations forums :
    Inscription : octobre 2009
    Messages : 344
    Points : 1 164
    Points
    1 164
    Par défaut
    Des portes ouvertes surement, malheureusement dans les faits les codes non testés correctement et passés en production sont encore légions
    Désolé pour les rétines, clavier QWERTY

  6. #6
    Membre régulier
    Homme Profil pro
    Développeur .NET
    Inscrit en
    août 2012
    Messages
    27
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Calvados (Basse Normandie)

    Informations professionnelles :
    Activité : Développeur .NET

    Informations forums :
    Inscription : août 2012
    Messages : 27
    Points : 88
    Points
    88
    Par défaut Null
    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.

  7. #7
    Membre régulier
    Homme Profil pro
    Inscrit en
    juillet 2013
    Messages
    49
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations forums :
    Inscription : juillet 2013
    Messages : 49
    Points : 108
    Points
    108
    Par défaut idées intéressante mais mal formulé
    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.

  8. #8
    Futur Membre du Club
    Homme Profil pro
    Développeur décisionnel
    Inscrit en
    février 2014
    Messages
    16
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 30
    Localisation : Maroc

    Informations professionnelles :
    Activité : Développeur décisionnel

    Informations forums :
    Inscription : février 2014
    Messages : 16
    Points : 5
    Points
    5
    Par défaut
    SVP mettez les liens hypertextes dans une couleur différente

  9. #9
    Inactif  

    Homme Profil pro
    Développeur .NET
    Inscrit en
    janvier 2012
    Messages
    4 905
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 63
    Localisation : Canada

    Informations professionnelles :
    Activité : Développeur .NET
    Secteur : Finance

    Informations forums :
    Inscription : janvier 2012
    Messages : 4 905
    Points : 10 173
    Points
    10 173
    Billets dans le blog
    36
    Par défaut
    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."
    À ma connaissance, le seul personnage qui a été diagnostiqué comme étant allergique au mot effort. c'est Gaston Lagaffe.

    Ô Saint Excel, Grand Dieu de l'Inutile.

    Excel n'a jamais été, n'est pas et ne sera jamais un SGBD, c'est pour cela que Excel s'appelle Excel et ne s'appelle pas Access junior.

  10. #10
    Inactif  

    Homme Profil pro
    NR
    Inscrit en
    juin 2013
    Messages
    3 715
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Suisse

    Informations professionnelles :
    Activité : NR
    Secteur : Aéronautique - Marine - Espace - Armement

    Informations forums :
    Inscription : juin 2013
    Messages : 3 715
    Points : 1 027
    Points
    1 027
    Billets dans le blog
    9
    Par défaut
    Un développeur ne fait plus que du code depuis très longtemps, aujourd'hui il fait le cahier des charges par exemple.

  11. #11
    Membre chevronné
    Homme Profil pro
    Consultant informatique
    Inscrit en
    septembre 2013
    Messages
    485
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Isère (Rhône Alpes)

    Informations professionnelles :
    Activité : Consultant informatique
    Secteur : Industrie

    Informations forums :
    Inscription : septembre 2013
    Messages : 485
    Points : 2 147
    Points
    2 147
    Par défaut
    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.

  12. #12
    Membre émérite
    Inscrit en
    janvier 2011
    Messages
    805
    Détails du profil
    Informations personnelles :
    Localisation : Autre

    Informations forums :
    Inscription : janvier 2011
    Messages : 805
    Points : 2 928
    Points
    2 928
    Par défaut
    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.

  13. #13
    Modérateur
    Avatar de gangsoleil
    Homme Profil pro
    Cyber sécurité
    Inscrit en
    mai 2004
    Messages
    9 713
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Haute Savoie (Rhône Alpes)

    Informations professionnelles :
    Activité : Cyber sécurité

    Informations forums :
    Inscription : mai 2004
    Messages : 9 713
    Points : 26 128
    Points
    26 128
    Par défaut
    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.
    "La route est longue, mais le chemin est libre" -- https://framasoft.org/
    Les règles du forum

  14. #14
    Inactif  
    Homme Profil pro
    Analyste-Programmeur / Intégrateur ERP
    Inscrit en
    mai 2013
    Messages
    2 511
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Analyste-Programmeur / Intégrateur ERP
    Secteur : Bâtiment

    Informations forums :
    Inscription : mai 2013
    Messages : 2 511
    Points : 10 150
    Points
    10 150
    Par défaut
    Citation Envoyé par Laurent 1973 Voir le message
    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...

  15. #15
    Expert éminent sénior
    Profil pro
    Inscrit en
    décembre 2007
    Messages
    5 860
    Détails du profil
    Informations personnelles :
    Localisation : France, Hérault (Languedoc Roussillon)

    Informations forums :
    Inscription : décembre 2007
    Messages : 5 860
    Points : 26 757
    Points
    26 757
    Par défaut
    Citation Envoyé par Zirak Voir le message
    (.../...)
    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.
    Les 4 règles d'airain du développement informatique sont, d'après Michael C. Kasten :
    1)on ne peut pas établir un chiffrage tant qu'on a pas finalisé la conception
    2)on ne peut pas finaliser la conception tant qu'on a pas complètement compris toutes les exigences
    3)le temps de comprendre toutes les exigences, le projet est terminé
    4)le temps de terminer le projet, les exigences ont changé
    Et le serment de non-allégiance :
    Je promets de n’exclure aucune idée sur la base de sa source mais de donner toute la considération nécessaire aux idées de toutes les écoles ou lignes de pensées afin de trouver celle qui est la mieux adaptée à une situation donnée.

  16. #16
    Rédacteur/Modérateur

    Avatar de yahiko
    Homme Profil pro
    Développeur
    Inscrit en
    juillet 2013
    Messages
    1 201
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Alpes Maritimes (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Développeur

    Informations forums :
    Inscription : juillet 2013
    Messages : 1 201
    Points : 7 563
    Points
    7 563
    Billets dans le blog
    43
    Par défaut
    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é... :/
    Tutoriels et FAQ TypeScript

  17. #17
    Membre du Club
    Profil pro
    Inscrit en
    novembre 2006
    Messages
    126
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : novembre 2006
    Messages : 126
    Points : 55
    Points
    55
    Par défaut
    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 !

  18. #18
    Rédacteur/Modérateur

    Avatar de SylvainPV
    Profil pro
    Inscrit en
    novembre 2012
    Messages
    3 260
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : novembre 2012
    Messages : 3 260
    Points : 9 544
    Points
    9 544
    Par défaut
    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
    One Web to rule them all

  19. #19
    Expert éminent sénior

    Profil pro
    Développeur informatique
    Inscrit en
    novembre 2006
    Messages
    6 855
    Détails du profil
    Informations personnelles :
    Localisation : France, Rhône (Rhône Alpes)

    Informations professionnelles :
    Activité : Développeur informatique

    Informations forums :
    Inscription : novembre 2006
    Messages : 6 855
    Points : 14 390
    Points
    14 390
    Par défaut
    Citation Envoyé par Amine Horseman Voir le message
    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..



    Citation Envoyé par el_slapper Voir le message
    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])

    Citation Envoyé par el_slapper Voir le message
    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.


    Citation Envoyé par el_slapper Voir le message
    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.
    Citation Envoyé par el_slapper Voir le message

    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
    Ce dont on ne peut parler il faut le taire ( Wittgenstein )

  20. #20
    Expert éminent
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    août 2007
    Messages
    2 066
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Ingénieur développement logiciels
    Secteur : High Tech - Multimédia et Internet

    Informations forums :
    Inscription : août 2007
    Messages : 2 066
    Points : 7 514
    Points
    7 514
    Par défaut
    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.

Discussions similaires

  1. Réponses: 5
    Dernier message: 08/03/2011, 15h26
  2. Ecrire un code en plus court
    Par NEC14 dans le forum Macros et VBA Excel
    Réponses: 18
    Dernier message: 18/10/2007, 09h33
  3. Pourquoi mon code est plus lent que Arrays.sort
    Par alexis779 dans le forum java.util
    Réponses: 3
    Dernier message: 12/12/2006, 12h44
  4. [MMX] Optimisation d'un code C++ -> plus lent
    Par Laurent Gomila dans le forum x86 32-bits / 64-bits
    Réponses: 12
    Dernier message: 17/05/2006, 18h47
  5. Code Asm plus lent que le C !!!
    Par themadmax dans le forum x86 32-bits / 64-bits
    Réponses: 7
    Dernier message: 23/01/2006, 18h21

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo