Discussion :

[infofree]

Voici un passage de l'excellent livre "Coder proprement" de Robert C. Martin

Certains pourraient prétendre qu’un livre qui traite du code est un livre dépassé – le code n’est plus le problème – et qu’il est plus important aujourd’hui de s’intéresser aux modèles et aux exigences. Il a même été suggéré que la fin du code était proche, qu’il serait bientôt généré au lieu d’être écrit, que les programmeurs seraient bientôt inutiles car les directeurs de projets généreraient les programmes à partir des spécifications.

Balivernes ! Nous ne pourrons jamais nous débarrasser du code car il représente les détails des exigences. À un certain niveau, ces détails ne peuvent pas être ignorés ou absents ; ils doivent être précisés. Préciser des exigences à un niveau de détail qui permet à une machine de les exécuter s’appelle programmer. Cette spécification est le code.
Je m’attends à ce que le niveau d’abstraction de nos langages continue d’augmenter. Je m’attends également à l’augmentation du nombre de langages spécifiques à un domaine. Ce sera une bonne chose. Mais ce n’est pas pour autant que le code disparaîtra.

Les spécifications écrites dans ces langages de plus haut niveau et spécifiques à un domaine seront évidemment du code ! Il devra toujours être rigoureux, précis et tellement formel et détaillé qu’une machine pourra le comprendre et l’exécuter.

Ceux qui pensent que le code disparaîtra un jour sont comme ces mathématiciens qui espèrent découvrir un jour des mathématiques qui n’ont pas besoin d’être formelles. Ils espèrent pouvoir trouver une manière de créer des machines qui réalisent ce que nous souhaitons, non ce que nous exprimons. Ces machines devront nous comprendre parfaitement, au point de pouvoir traduire nos besoins exprimés de manière vague en des programmes opérationnels qui répondent précisément à ces besoins.

Cela ne se produira jamais. Même les humains, avec toute leur intuition et leur créativité, ne sont pas capables de créer des systèmes opérationnels à partir des vagues sentiments de leurs clients. Si la spécification des exigences nous a enseigné quelque chose, c’est que les exigences parfaitement définies sont aussi formelles que du code et qu’elles peuvent servir de tests exécutables pour ce code !

N’oubliez pas que le code n’est que le langage dans lequel nous exprimons finalement les exigences. Nous pouvons créer des langages plus proches des exigences. Nous pouvons créer des outils qui nous aident à analyser et à assembler ces exigences en structures formelles. Mais nous n’enlèverons jamais une précision nécessaire. Par conséquent, il y aura toujours du code.

Je partage son point de vue et je trouve son argumentation très pertinente

Et vous ?

Que pensez-vous de la position de l'auteur?
Peut-on se débarrasser du "code"? autrement dit, est-ce que le métier de développeur est amené à disparaître ?

[rmaker]

Oui, l'article est intéressant. Et pourtant, la question n'est (à mon humble avis) plus celle là. Bien sûr que l'on va toujours coder.

Maintenant, coder quoi? Le besoin spécifique de notre client. Tout le reste a déjà été préparé: persistance, IHM, bibliothèques de tests. On n'écrit par exemple que très peu de code pour gérer nos bases de données. On ne se fait plus plaisir à coder un unit of work, un lazy loading, ou un protocole de communication RPC ou web service. Pour tout çà, il y a des frameworks.

Notre travail n'est donc pas d'écrire du beau code et de résoudre des problématiques techniques captivantes. C'est coder l'expression du besoin fonctionnel. C'est assembler des frameworks et les configurer. En ce sens, oui on code. Maintenant, est ce qu'on code des choses intéressantes? Je vous laisserai répondre à cette question.

[I_believe_in_code]

(...) autrement dit, est-ce que le métier de développeur est amené à disparaître ?

A disparaître ? Non.
A devenir de moins en moins intéressant ? Oui.
De moins en moins difficile ? Sans doute.

On va continuer à avoir besoin de développeurs, oh que oui, mais on aura de moins en moins besoin de très bons développeurs ou de "grosses tronches".

[infofree]

Je me dis que même si la conception d'applications consistera à imbriquer des modules, des briques, tout faits, comme le préfabriqué en bâtiments qu'on mettra à disposition des utilisateurs en tant que kits de dev... n’empêche que c'est des développeurs qui vont créer, développer ces modules

[rmaker]

On va continuer à avoir besoin de développeurs, oh que oui, mais on aura de moins en moins besoin de très bons développeurs ou de "grosses tronches".

Cà m'attriste, mais c'est tout à fait vrai, en tous cas en SS2I. Après, on lit deux modes qui se détachent, et qui peuvent être très intéressantes:
- big data, à force de sauver des données, autant en faire quelque chose
- cloud, effet de mode ou pas...

[Logan Mauzaize]

Voici un passage de l'excellent livre "Coder proprement" de Robert C. Martin

Je partage son point de vue et je trouve son argumentation très pertinente

Et vous ?

Que pensez-vous de la position de l'auteur?
Peut-on se débarrasser du "code"? autrement dit, est-ce que le métier de développeur est amené à disparaître ?

Le "code" disparaîtra peut-être un jour, on a encore le temps de voir venir, mais le codage/développement non. Il suffit de s'intéresser aux activités de spécification/modélisation pour résumer en deux mots : raffinement (les détails) et transformation (langage formel).
Ce que fait déjà tout développeur lambda quand il écrit du code à partir d'une source (spécification, analyse, incident, etc.) plus ou moins formelle (en termes de langage).

Ensuite il y a des problématiques qui sont réellement du détail fonctionnel mais des énormes casses-têtes techniques : concurrence, indexation, etc.
Et c'est la que les bons développeurs font la différence.

Enfin dernier point, certaines problématiques peuvent être couvertes par plusieurs solutions chacune avec ces avantages et ces inconvénients. On fait implicitement des choix quand on code. Exemple tout bête : liste chaînée ou liste "tabulaire" ?
Si t'es pas codeur, tu auras dû mal à considérer/évaluer/noter/prioriser les arguments. Sans compter sur l'estimation de l'impact en intégration au sein du système étudié mais aussi dans sa globalité. Si je reprend l'exemple de mes listes

1. il faut que je m'intéresse à si je fais beaucoup d'insertion ?
2. est-ce qu'elles se font toujours à la fin ?
3. est-ce que je fais des tris ? Ou de la recherche ?
4. est-ce que je n'ai pas un mélange des deux ?
5. est-ce que je peux déterminer à l'appel le type qui me conviendrait ?
6. est-ce que je fais des insertion/recherche dans un même algorithme ?
7. ...

Et il s'agit d'un problème simple, bien compris et isolé. Imaginez maintenant un problème à plus grande échelle, avec plus de couches, plus de systèmes tiers, etc.

[gangsoleil]

Peut-on se débarrasser du "code"? autrement dit, est-ce que le métier de développeur est amené à disparaître ?

Pour moi, c'est exactement comme les gens qui predisaient que l'industrie (ie la fabrication de produits physiques) n'avait plus sa place dans les pays occidentaux, et que tout serait construit en Chine ou dans d'autres pays dans lesquels la main d'oeuvre est a bas cout.

Sauf qu'aujourd'hui, apres des annees de delocalisation, on voit de plus en plus d'entreprises rappatrier leur production dans des pays occidentaux, pour plusieurs raisons, dont le cout de la main d'oeuvre (+400% en Chine sur quelques annees), le manque de reactivite du a la distance (c'est plus long de faire reagir des equipes a distance que localement), du manque de fiabilite (certaines chaines de production ont un taux de defaut de plus de 30%), ...

C'est pareil pour le code : certaines entreprises ont voulu delocaliser (SUN a Bengalore pour les grands, des PMEs en Inde, en Roumanie ou en Russie, ...), mais je ne connais pas d'entreprise qui ait vraiment reussi cette delocalisation.

Donc a mon sens, ca va.

[rimram31]

On joue sur les mots avec le verbe "coder". Si on entend par coder écrire des lignes de programme, ben oui, on code de moins en moins et la tendance ne va pas se démentir, par contre comme cité dans le post initial, si on appelle coder transformer une exigence/spécification en produit fini, fabriquer tout simplement, bien entendu qu'il y aura toujours de la fabrication informatique.

Depuis plus de vingt ans que je suis dans ce métier, une évidence de constater que la part "codage" dans un projet est de plus en plus courte car nous avons a disposition des outils et composants plus élaborés qui nous évite de recoder "from scratch". On peut s'amuser a un parallèle avec l'électronique, plus personne ne fabrique un circuit électronique à partir de composants élémentaires, on prend deux trois composants de haut niveau et on assemble le tout. Il en devient de même pour l'informatique.

Pour autant, il faudra bien qu'il y ait quelques développeurs pour fabriquer ces composants de haut niveau avec des langages, eux, de bas niveau et d'autres pour les utiliser et les intégrer avec des outils/technologies de plus haut niveau. Encore une fois, tout dépend ce que l'on entend par "coder", maintenant le métier étant sensiblement différent, les qualités faisant un "bon développeur" sont elles aussi différentes. J'en parlais dans un autre post sur ce sujet, la communication, qui n'est pas une qualité très répandue chez ceux attirés par l'informatique, devient plus importante que le talent de "codeur".

[infofree]

Ce qui est sur c'est que une des conséquences est l'apparition de nouveaux métiers IT

[souviron34]

En fait, ce débat me fait un peu penser à la mécanisation des chaînes..

Il y a une 40aine d'années, tout le monde réclamait et érigeait en panacées les robots industriels, la mécanisation, qui "libérerait" les hommes...parallèllement, on fondait l'avenir sur l'obtention de diplômes pour tous, et la fermeture des mines et l'éradication des travaux "pénibles"..

Aujourd'hui, on réclame à grands renforts de manifs et grèves le retour de l'emploi industriel (voir Florange et autres).. Le BTP a du mal à recruter.. On a du mal à trouver un plombier ou électricien qualifié, surtout faisant des réparations.. et les diplômés se plaignent du chômage et de bas salaires..

Comme quoi "la robotisation" n'est pas forcément un idéal vers lequel il faudrait tendre..


L'exemple de l'électronique est intéressant à ce sujet : on n'a presque plus d'éléctriciens réparateurs. Du coup, cet effet cumulé à "l'obsolescence programmée" des cartes et matériels fait que l'on est à fond dans le système de surconsommation : ce qui aurait coûté 50 euros (changer un condensateur ou une résistance ou une diode, qui chacun vaut 50 cents), dont 99% pour l'électricien, avec un appareil qui aurait plus que doublé sa durée de vie, maintenant coûte 400 euros, car on doit changer la machine complète..et on enrichi des grosses boites, se basant à fond sur les fameuses "délocalisations" (ben oui.. Sinon ça ne deviendrait plus intéressant de vendre une machine complète à la place d'un composant simple, on pollue, et on épuise les ressources de la Terre par un gaspillage effréné..

Si on se base là-dessus, dans 30 ans on ne trouvera plus de "codeurs" capables (ou voulant) rentrer dans le code (qui sera d'ailleurs généré automatiquement), et pour une bête histoire de format d'entrée qui change on vous conseillera de changer votre logiciel... Même si 99.8% de la fonctionalité n'est pas dans le format d'entrée..

Je n'ose imaginer ce que cela pourrait donner pour un logiciel "in house"... Etant donné l'argent et le temps nécessire à faire un bon soft, en refaire un est prohibitif... Surtout si c'est à cause de 0.02% du tout...

Quant aux "nouveaux métiers", ce qu'on voit sur une longue période, c'est une évolution des métiers partant de relativement peu de personnel, assez spécialisés (cobol) ou très formés (ingéniéurs), vers une multitude de é"métiers" cloisonnés, hyper-pointus, difficilement évolutifs, relativement peu formés de manière générale (uniquement sur le dernier outil ou la dernière techno) et surtout "malléables et corvéables à merci", de la "chair à canon" quoi...

Comme pour l'industie lourde, où la "robotisation" a amené inexorablement aux concepts de "délocalisations"..


Honnêtement je ne sais pas si c'est ce qu'il faut souhaiter...

[rimram31]

...Honnêtement je ne sais pas si c'est ce qu'il faut souhaiter...

Point de vue intéressant d'autant que la délocalisation est déjà effective ! Je parlais plus haut de deux métiers déjà existants, ceux qui fabriquent les composants de "bas niveau" et ceux qu intègrent, les premiers sont délocalisés, la plupart des centre de recherche et développement des acteurs de l'informatique ne sont plus en occident. On peut même craindre a raison que peu a peu quantité de besoins soient satisfaits par des services en ligne "standards" faisant aussi disparaitre, en tout cas diminuer fortement, le besoin d'intégrateurs locaux, tout autant que le support qui sera assuré off shore.

Ca fait un peu froid dans le dos ...

[souviron34]

Ca fait un peu froid dans le dos ...

A moins que, forts de l'expérience des 40 années précédentes, nous ne luttions tous (ou en tous cas en nombre suffisant) pour une non-automatisation globale, contre le jeunisme et le renouvellement systématique des technologies tous les 2 ou 3 ans, contre l'apparition de "bulles" soutenues par des buzz-words et du marketing à toute épreuve... et contre l'affublage permanent de l'étiquette "sale" ou "inutile" au codeur, à la façon de comprendre comment une machine marche (quelques discussions sur les GC me reviennent en mémoire), sur le non-gaspillage des ressources sous le prétexte que "c'est pas cher la mémoire" ou "c'est pas cher des DD" ... ou, comme il est mentionné dans d'autres débats, contre les idées "post-modernes" (je fais mon André Manoukian ) que "Le Savoir est disponible pour tous gratuitement grâce au Dieu Web" et que tout doit s'obtenir sans effort (j'ai eu beaucoup de mal à lire qu'un jeune chercheur me dise que c'était un comble d'avoir à se déplacer pour aller trouver un livre ou une revue dans une bibliothèque !!!)

Bref, se battre pour une informatique basée sur l'humain et l'intelligence et non pas sur des robots générateurs de code pace que "pondre du code est bête"... contre la fainéantise intellectuelle généralisée sous prétexte de modernité;;;


Non.. Pondre du bon code est une activité intelligente... qui nécessite réflexion, formation, discussions... et travail...

Comme être un bon maçon, un bon éléctricien, ou un bon mécano ou ingénieur hydraulque ou des Ponts et Chaussées..


Cela signifie lutter contre tous les marketeux (et ils sont nombreux et puissants ces temps-ci dans nos métiers) qui dénigrent toutes les choses comme "has been", et contre tous les flatteurs lèche-cul qui vous disent "arf.. Mais coder c'est bon pour les nuls. Toi tu vaux mieux que ça.. Tu feras un bon achitecte XXX" ou autres flagorneries du même acabit, qui flattent l'égo en désignant comme "indigne de vous" des basses besoignes comme coder ou savoir comment une machine fonctionne... (ce qui est exactement le même discours qu'on a tenu il y a 40 ans aux ouvriers et aux élèves ces 30 dernières années en leur disant pour les uns "arff.. le travail pénible c'est nul.. Tu verras, piloter un robot ça c'est digne de toi" et pour les autres "arff.. le travail manuel c'est nul.. Tu verras, avoir un diplôme ça c'est digne de toi"...)


My 2 cents..



PS: ce serait d'ailleurs un combat écologiqque la consommation de ressources naturelles étant mutlipliée à chaque nouveau coeur installé dans un multi-core pour faire du traitement de texte ou du Photoshop (slilicium, terres rares, plastique, composants électroniques, ventilateurs, consommation électrique, étain des soudures sur les cartes, ...), à chaque nouvelle réécriture d'un code marchant parfaitement mais d'une technologie taxée "d'obsolète".... Il y aurait plein de boulot à faire des choses nouvelles, et non refaire les anciennes, ou à les faire évoluer, ou les réparer... plutôt que de les jeter à la poubelle...

Bref, non à la société de surconsommation. Non à la décroissance. Et oui à une croissance raisonnée

[BenoitM]

A devenir de moins en moins intéressant ? Oui.

Perso je ne trouve pas spécialement interresant de pisser des lignes de code.
Je trouve plus gratifiant de comprendre les conceptes de fonctionnement d'une entreprise que de passer mon temps à écrire le code d'un select/update/delete.

[BenoitM]

Il y a une 40aine d'années, tout le monde réclamait et érigeait en panacées les robots industriels, la mécanisation, qui "libérerait" les hommes...parallèllement, on fondait l'avenir sur l'obtention de diplômes pour tous, et la fermeture des mines et l'éradication des travaux "pénibles"..

Aujourd'hui, on réclame à grands renforts de manifs et grèves le retour de l'emploi industriel (voir Florange et autres).. Le BTP a du mal à recruter.. On a du mal à trouver un plombier ou électricien qualifié, surtout faisant des réparations.. et les diplômés se plaignent du chômage et de bas salaires..

Comme quoi "la robotisation" n'est pas forcément un idéal vers lequel il faudrait tendre..

Pas sur que de nombreux manifestants accepteraient de retourner travailler dans les mines.
L'emplois industriel n'a plus grand chose a voir avec les conditions d'antant.

Puis bon le problème c'est peut-etre que le système change mais que la société n'évolue pas.

De plus la pauvreté n'est plus la pauvreté d'autant. Avant être pauvre c'était n'avoir rien et avoir des difficulter de se nourir.
Maintenant la pauvreté c'est avoir un smartphone, une écran plat un ordi, internet et d'avoir des difficulter à se nourir.

Il faudrait peut-être trouvé un système ou la production de bien coûte cher et les services sont bon marché plutot que l'inverse.
Sans parler de la globalisation des marchés mais sans globalisation des salaires

[el_slapper]

Perso je ne trouve pas spécialement interresant de pisser des lignes de code.
Je trouve plus gratifiant de comprendre les conceptes de fonctionnement d'une entreprise que de passer mon temps à écrire le code d'un select/update/delete.

Je trouve qu'on pisse autant de code à determiner si un avis d'échéance sera payé par chèque, virement, ou TIP, qu'à créér les éléments techniques qui mettent en oeuvre ce choix.

Il me semble que le message original, que je soutiens, c'est que les éléments techniques peuvent être encapsulés, et laissés de plus en plus à de rares spécialistes, mais que les éléments fonctionnels, eux, seront toujours présents.

Après, plus on moins interessant, chacun son truc. Je préfère le fonctionnel, mais j'en connais qui préfèrent la technique.

[souviron34]

Perso je ne trouve pas spécialement interresant de pisser des lignes de code.
Je trouve plus gratifiant de comprendre les conceptes de fonctionnement d'une entreprise que de passer mon temps à écrire le code d'un select/update/delete.

Nous ne travaillons pas dans les mêmes domaines, mais perso moi je trouve aussi intéressants les 2 aspects : comprendre les concepts de fonctionnement d'une entreprise, et coder pour pouvoir aider les utilisateurs... Si possible d'une manière efficace et intelligente..

Je ne vois aucune incompatibilité ou barrière entre les 2 aspects, bien au contraire...

[rimram31]

Perso je ne trouve pas spécialement interresant de pisser des lignes de code.
Je trouve plus gratifiant de comprendre les conceptes de fonctionnement d'une entreprise que de passer mon temps à écrire le code d'un select/update/delete.

Ah, ça dépend :-) si l'action de "pisser du code" a une incidence fonctionnelle/business, le jeu en vaut alors la chandelle (et est alors valorisant) et partie prenante de la compréhension des "concepts de fonctionnement de l'entreprise" en décidant de coder quelques select/update/delete si l'effort permet un gain.

Je peux citer nombre d'exemples "tout bêtes" de mettre quelques heures "les mains dans le cambouis" avec pour résultat une machine gagnée, de la ram en moins, des heures de support ... Tout est question de ROI (prise en compte de la maintenance comprise) notion malheureusement assez étrangère a nombre d'informaticiens focalisés trop souvent sur le résultat fonctionnel plus que celui du coût global. Mais là, j'ouvre un autre débat

[I_believe_in_code]

Je trouve plus gratifiant de comprendre les conceptes de fonctionnement d'une entreprise que de passer mon temps à écrire le code d'un select/update/delete.

Moi aussi. D'ailleurs celui qui me verra travailler sur du code ne représentant aucun intérêt à mes yeux n'est pas encore né, et son père non plus.

[BenoitM]

Ah, ça dépend :-) si l'action de "pisser du code" a une incidence fonctionnelle/business, le jeu en vaut alors la chandelle (et est alors valorisant) et partie prenante de la compréhension des "concepts de fonctionnement de l'entreprise" en décidant de coder quelques select/update/delete si l'effort permet un gain.

Je peux citer nombre d'exemples "tout bêtes" de mettre quelques heures "les mains dans le cambouis" avec pour résultat une machine gagnée, de la ram en moins, des heures de support ... Tout est question de ROI (prise en compte de la maintenance comprise) notion malheureusement assez étrangère a nombre d'informaticiens focalisés trop souvent sur le résultat fonctionnel plus que celui du coût global. Mais là, j'ouvre un autre débat

Il y a pissé et pissé
Part exemple dans pisser du code j'entends créer une classes, ses propriétés, un construceurs de copie, s'amuser à déclarer les interfaces de IDAL les methodes du service web déclaré les méthodes qui sont du coté du client pour appeller les methodes du service web.
Perso j'ai crée un générateur de code pour faire ca.
Et puis certes j'ai été content quand j'ai fait ma premiere liste chainé en c avec des pointeurs mais je suis quand meme content d'utiliser du C# ou Java qui l'implémente par défaut.

[mumen]

Voici un passage de l'excellent livre "Coder proprement" de Robert C. Martin



Je partage son point de vue et je trouve son argumentation très pertinente

Et vous ?

Que pensez-vous de la position de l'auteur?
Peut-on se débarrasser du "code"? autrement dit, est-ce que le métier de développeur est amené à disparaître ?

Oui, je partage ce point de vue.

Non, je ne pense pas que l'on se débarrassera du code (avec ou sans guillemets) étant entendu que le codage, est un mode d'expression amené à évoluer et que demain on appellera ça peut être autrement. La persistance des langages ancestraux (!) comme l'assembleur est directement liée aux machines qu'il faut donc obligatoirement associer à l'équation.

Coder, c'est abstraire du réel à destination d'une machine.

• Les manifestations du réel sont infinies, impossible à totalement prévoir. Sur le même trottoir de la ville, deux marchands de chaussures : deux besoins distincts et incompatibles.

• Abstraire du réel, c'est comme parler. Se poser la question de savoir si demain il ne restera plus rien à coder est peut être la même chose que de se demander si demain on aura fait le tour de tout ce que l'on peut dire ou écrire avec les mots, avec le langage des hommes. D'ailleurs ce sont bien des langages -de programmation- qui nous servent à coder.

• Les machines -hard et soft- évoluent. Il faudra forcément tout réécrire, encore et toujours.

Si le codage doit s'arrêter un jour, ce ne sera qu'avec l'arrêt des machines. En attendant, on est dans la possibilité de s'attendre à une vulgarisation drastique du codage dans un avenir mystérieux.

Finalement, c'est notre quête à tous, codeurs, que ce soit plus facile pour tous les utilisateurs.

La question ici posée est de savoir si nous y arriverons un jour au point de nous rendre inutiles ! Il existe raison hypothétique qui pourrait faire s'arrêter le codage. Ce serait l'arrêt de l'évolution humaine. Les machines feraient tout ce qui est utile et nécessaire sans qu'aucun changement ne semble utile ou nécessaire. Ce qui est soit une utopie... soit une tyrannie. Donc des situations éminemment transitoires !

Moi je crois que le codage ne cessera jamais tant que les machines fonctionneront, mais que demain on cessera de parler de codage, parce que tout le monde codera.