Discussion :

[carpool]

je suis fondateur de 2 startups web, je trouve l'article hyper juste, il correspond précisément à l'expérience que j'ai eue, d'abord en travaillant avec des développeurs médiocres, puis avec des bons.

le fait d'accepter et d'intégrer le changement permanent est vital. un développeur qui veut un énorme cahier des charges à la commande sans accepter les changements futurs voue un projet à l'échec. les projets qui marchent sont ceux qui sont capables d'évoluer en permanence; pour cela il faut un code évolutifs.

d'ailleurs cette tolérance au changement, le fait que les idées viennent le soir dans le lit, etc... n'est pas propre à la programmation, mais à tout travail créatif (idem pour chef d'entreprise)

s'ils y a des ingénieurs qui adhèrent à cette vision, je cherche d'ailleurs un directeur technique pour le site www.voiturelib.com (location de voitures entre particuliers)

[maske]

les 12 lignes par jour ne me choque pas du tout. On parle bien de lignes effective donc il faut enlever les commentaires, les tests unitaires. Après il l'aspect documentation à savoir les docs de conceptions, fiche de tests et j'en passe... Tout ceci a un coût rapporté en ligne de codes, ça baisse énormément.

Moi je commente très peu, je ne documente pas la conception à la volée, ni le système, je ne fais pas les fiches de scénarios de tests (pas mon rôle dans mon équipe), etc... Mais si je compte uniquement le code utile au final (sans les tests, commentaires, etc...), on est bien au dessus des 12 lignes par jour, en comptant par dessus la réflexion, les discussions, la documentation, etc...

Du coup ça fait de moi un mauvais programmeur selon l'article, mais étant donné que mes collègues sont plus ou moins dans la même veine, je ne suis pas sûr de l'absolu de ces "six vérités".

Un responsable informatique m'a raconté que c'était à peu près une constance quelques soient les langages utilisés

Ben c'est étrange que ça ne soit pas ce qui se voit en entreprise.

Non, parce quand t'es un excellent programmeur, tu te débrouilles pour refiler le boulot à quelqu'un d'autre. Que ça soit un générateur de code auquel tu comprends rien, ou un mec lambda qui veut absolument participer à ce mouvement humanitaire qu'est l'open-source

Euhh pas sûr d'avoir compris...

Un bon développeur, va consommer une journée à dessiner des tableaux logiques, pour lister tous les cas possibles, éliminer ceux qui ne servent à rien. Et ensuite le faire en une heure.

C'est quand même bien simpliste (limite caricatural) comme vision des choses.

Des fois on a un chef (ou un client) qui ne nous laisse pas le luxe de passer une journée à faire des dessins (et c'est le drame).

Parfois on a besoin de réfléchir une heure et de programmer une demi-journée, parce que c'est simple, mais long.

Et on peut trouver beaucoup de cas qui se contredisent.

Idéalement, on réfléchit vite et on code vite. C'est rarement le cas (ou alors au prix de certaines choses). Dans la plupart des cas, c'est un compromis entre ce qu'on voudrait idéalement et ce qu'on a le temps de faire.

Donc pour moi vouloir établir en six règles ce qu'est ou pas un bon programmeur, c'est de la connerie.

[X0000]

+1 tout simplement.

[chemanel]

Parfois on a besoin de réfléchir une heure et de programmer une demi-journée, parce que c'est simple, mais long.

Aurais tu un exemple concernant cette phrase ? ça m'intéresse beaucoup.

[Gunny]

12 lignes c'est à peine une boucle for avec un peu de traitement...
Je suis totalement d'accord sur le fait que coder effectivement ne représente au final qu'une petite partie du boulot, personnellement je passe beaucoup plus de temps à réfléchir à ce que je vais faire et comment... mais quand même !

[maske]

Aurais tu un exemple concernant cette phrase ? ça m'intéresse beaucoup.

Une gestion de paramètres statiquement fixés dans une spec, qui doivent être initialisés statiquement au début d'un programme, avec beaucoup de cas ?

C'est long, c'est chiant, mais ça ne nécessite pas forcément un jour de réflexion.

[el_slapper]

rappel : 12 lignes par jour, c'est une moyenne. Sur 10, 15 ou 20 ans. Evidemment, les 2 premières années, vous serez à 100 ou plus. Mais très vite ça va baisser, parceque l'existant marche, est compliqué, et que modifier un truc demande de plus en plus de travail de recherche, de vérifications et de tests.

Parfois même, on retire des lignes. L'autre jour, j'ai remplacé 2000 lignes par 300 lignes - pour rajouter un cas et refactoriser le bidule. -1700 lignes sur le projet. Même avec tout ce que je vais rajouter, il est possible que ce projet de 45 jours soit négatif en nombre de lignes. ça réduit la moyenne, bizarrement.....

[Thierry B.]

rappel : 12 lignes par jour, c'est une moyenne. Sur 10, 15 ou 20 ans.

C'est sûr que calculer la moyenne de lignes codées par jour sur 15 ans d'un projet de 3 mois ça fait tout de suite baisser la moyenne...

L'idée de base je suis relativement d'accord, après comme dit plus haut, c'est archi-caricatural et "un peu" poussé sur les chiffres...

[_skip]

Quoi qu'il en soit, je trouve que mesurer sa contribution à un projet en lignes de code c'est juste débile. En plus avancer un chiffre c'est assez gonflé.

Et employer des solutions existantes pour ne pas avoir besoin de réinventer la roue c'est bien, cependant quand je vois des sites web tout simples de gestion de contacts faits avec plein de frameworks qui font de la réflexion, de l'injection de dépendances, des trucs qui confinent à la magie noire et qui laissent des stacktrace de 25m incompréhensibles en cas d'erreur d'initialisation, ça me fait doucement rire.

En bref cet article, je le trouve assez bof finalement, c'est un peu catégorique de dire "les bons y font comme ça" "les mauvais y font comme ci".
Pour moi, si l'application remplit le besoin du client, respecte les délais tout en étant simple à maintenir, c'est que le développeur a bien bossé.

Ce ne sont pas les kilomètres de diagrammes au crayon papier ou le fait qu'on ait eu ses idées sous la douche ou devant son IDE qui y changent grand-chose. Pas plus que le fait d'avoir suivi à la lettre les design patterns ou architectures X tiers, d'avoir écrit ses tests unitaires avant ou après l'implémentation, d'avoir dépassé l'apport journalier moyen de X lignes de code par jour et j'en passe.

En gros je me méfie de ces super-programmeurs qui assènent leur vision des choses sur leur blog sans aucune nuance, telle la vérité absolue.

[dams78]

j'imagine s'il s'agissait de construction automobile , batiment , aéronautique , production d'énergie nucléaire , médecine ...

à part les prévisions météorologiques , existe-t-il un autre secteur où on puisse se permettre de tels chiffres ?

on est dans une industrie du luxe tout de même

L'informatique est un domaine relativement jeune aussi, c'est pour ça qu'on essuie un peu les plâtres.
Par exemple, je sais pas si c'est le cas chez vous, mais moi j'ai souvent connu des situations d'externalisation parce que c'était "à la mode" et maintenant j'entends de plus en plus parler des méthodes agiles et de la proximité des équipes.

[el_slapper]

C'est sûr que calculer la moyenne de lignes codées par jour sur 15 ans d'un projet de 3 mois ça fait tout de suite baisser la moyenne...

sauf que le programme a tendance à durer 10 ans et à être maintenu sur l'essentiel de sa durée de vie. Si tu ne fais que du projet tout neuf tout beau, et puis que tu passes à un autre projet tout neuf tout beau, alors tu ne connais pas grand chose de ce qui constitue l'essentiel du travail de la majorité des gens ici : la maintenance. Un projet, c'est un départ très productif, puis plein d'aménagements, dont beaucoup ne créent pas, ou peu de lignes de code. Voire en détruisent.

L'idée de base je suis relativement d'accord, après comme dit plus haut, c'est archi-caricatural et "un peu" poussé sur les chiffres...

Non. C'est juste lissé sur l'ensemble du travail de gens. Moi, je dois être très en-dessous, même en comptant ma journée à 1000 lignes.

[Eric2a]

le fait que les idées viennent le soir dans le lit, etc... n'est pas propre à la programmation, mais à tout travail créatif

+1

[el_slapper]

Quoi qu'il en soit, je trouve que mesurer sa contribution à un projet en lignes de code c'est juste débile. En plus avancer un chiffre c'est assez gonflé.

Il fut un temps ou les devs étaient payés à la ligne de code. Il m'arrive de maintenir l'héritage de ces temps obscurs. C'est infâme.

Et employer des solutions existantes pour ne pas avoir besoin de réinventer la roue c'est bien, cependant quand je vois des sites web tout simples de gestion de contacts faits avec plein de frameworks qui font de la réflexion, de l'injection de dépendances, des trucs qui confinent à la magie noire et qui laissent des stacktrace de 25m incompréhensibles en cas d'erreur d'initialisation, ça me fait doucement rire.

ou, comme dit précédemment, faire une archi 3-tiers pour un misérable site web de madame michu et ses photos de vacances. L'inverse est vrai aussi : un seul programme de 35000 lignes pour controler et enrichir une centaine de flux différents, avec pas moins de 72 référentiels différents appelés(authentique).

En bref cet article, je le trouve assez bof finalement, c'est un peu catégorique de dire "les bons y font comme ça" "les mauvais y font comme ci".
Pour moi, si l'application remplit le besoin du client, respecte les délais tout en étant simple à maintenir, c'est que le développeur a bien bossé.

Mais tous n'en sont pas capables.

Ce ne sont pas les kilomètres de diagrammes au crayon papier ou le fait qu'on ait eu ses idées sous la douche ou devant son IDE qui y changent grand-chose. Pas plus que le fait d'avoir suivi à la lettre les design patterns ou architectures X tiers, d'avoir écrit ses tests unitaires avant ou après l'implémentation, d'avoir dépassé l'apport journalier moyen de X lignes de code par jour et j'en passe.

Mais chacun a ses limites. Au plus le projet est gros, et au moins on trouvera de gens capables de programmer à vue de nez. J'ai fait pas mal de belles choses à l'instinct, mais quand la complexité dépasse ma cervelle, alors papier-crayon deviennent indispensables. Sinon.....

[Thierry B.]

sauf que le programme a tendance à durer 10 ans et à être maintenu sur l'essentiel de sa durée de vie. Si tu ne fais que du projet tout neuf tout beau, et puis que tu passes à un autre projet tout neuf tout beau, alors tu ne connais pas grand chose de ce qui constitue l'essentiel du travail de la majorité des gens ici : la maintenance. Un projet, c'est un départ très productif, puis plein d'aménagements, dont beaucoup ne créent pas, ou peu de lignes de code. Voire en détruisent.

Euh... les 12 lignes de code c'est bien pour un développeur "par jour" non ? Pas "par jour par projet"... parce qu'il y a confusion je crois

[Nebulix]

La phrase suivante n'a pas été reprise du blog original :

“A great lathe operator commands several times the wage of an average lathe operator, but a great writer of software code is worth 10,000 times the price of an average software writer.” –Bill Gates

Dommage
Je doute un peu du fait que ce Bill paie certains programmeurs 10,000 fois plus que d'autres.
Je ne doute pourtant pas que certains soient payés 10,000 fois plus que d'autres, dans sa boite.
Moralité ?

[Caly4D]

Aurais tu un exemple concernant cette phrase ? ça m'intéresse beaucoup.

moi j'en ai un en 4D, lorsque tu veux imprimer un document et que tu utilise la commande "imprimer ligne"

C'est simple à mettre en oeuvre mais long à écrire puisque tu dois définir toi même toutes les lignes qui seront imprimer et mettre des condition partout pour voir si tu dépasses la tailles de la page.

j'aurais bien mis un morceau de code mais y'a pas de balise spoil et ça plomberai le topic

(en fait la 1ere fois que tu le fais tu réfléchis un après midi puis lorsque tu fais un truc cazi similaire en 1/2h tu sais à quoi ta méthode va ressemblé mais il te faudra 3-4 heures pour la coder et faire les tests pour voir si tu t'es pas planté)

bien entendu c'est plutot rare de réfléchir 1/2h pour coder 4h…

[maske]

bien entendu c'est plutot rare de réfléchir 1/2h pour coder 4h…

Ben personnellement, j'ai récemment eu à réfléchir quelques minutes pour coder 4 heures derrière (quasiment).

[aimad41]

la question c'est comment expliquer à mon crétin de patron que je passe 75% de mon temps à réfléchir sur la conceptualisation d'une application, comment lui expliquer qu'un bon ingénieur n'est pas censé coder tout le temps sur son écran c'est complètement ridicule et stupide de voir le programmeur de tel façon, agréablement surpris par ces propos j'dois l'avouer pour le coté "rassurant" merde suis-je censé réfléchir tout le temps au risque de perde en productivité? débat ouvert!

[Arnard]

@Aspartame : un projet considéré comme un échec n'est pas forcément un projet non livré ou empli de bug, c'est avant tout un projet qui a dépassé les contraintes de temps/coût définies au début.

[Génoce]

@Aspartame : un projet considéré comme un échec n'est pas forcément un projet non livré ou empli de bug, c'est avant tout un projet qui a dépassé les contraintes de temps/coût définies au début.

Effectivement, la on comprends mieux les chiffres