Discussion :

[Invité]

@souviron34

Il y a des refontes qui aboutissent. Celles que tu décris, où l'on jette les anciens, et où l'on s'acharne à surtout ne rien faire qui ressemble de loin ou de près au système précédent, ne mènent à rien. Mais si on a un responsable technique raisonnable, on peut garder les bonnes idées de l'ancien système, et apprendre des régressions passées. C'est souvent le cas quand la refonte est rendue obligatoire par une contrainte technique (évolution matérielle contraignante, par exemple).

Au global, ca coute une bombe et c'est très démoralisant (pour les raisons que tu cites), mais on peut arriver à une version améliorée du programme précédent. Au final, on y gagne, mais le cout est prohibitif.

@Franck Soriano

Il y a un problème de fond dans cette démarche dans laquelle on a un architecte qui "conçoit librement", puis un CP qui exécute sous contrainte. Et dans la situation que tu décris, l'architecte porte une lourde responsabilité dans l'échec du projet... Imaginer une "oeuvre d'art" théorique sans prendre en compte la réalité de l'équipe de developpement, c'est totalement irresponsable.

Ce fait un peu penser à une citation fameuse de Kernighan:
"Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it."
(Debuguer est deux fois plus difficile qu'écrire le code original. Aussi, si on écrit le code le plus intelligent dont on est capable, on n'est, par définition, pas assez malin pour le débuguer.)

Personnellement, je me suis toujours interrogé sur la validité de cette fonction d'architecte. Elle fait bien sur rêver les informaticiens (on "crée" sans jamais avoir à mettre les mains dans les détails dégoutants), mais en pratique, j'ai beaucoup de mal à voir son utilité, sauf à impliquer l'architecte dans la réalisation...

Je trouve aussi qu'en termes de responsabilités, il est beaucoup plus facile d'assumer un nouveau projet que de maintenir un produit existant.

Je suis bien d'accord. Mais c'est extrèmement difficile à faire passer, malheureusement. J'explique souvent à mes clients que sur un développement court (disons moins d'un an), le cout annuel de maintenance est compris entre le quart et la moitié du cout initial de développement (généralement la moitié en année 1, car on ajoute toutes les fonctions "oubliées", ensuite ca baisse). C'est une évaluation fondée sur pas mal d'observations, et elle est généralement correcte (dans mon domaine en tous cas). Mais elle est invendable. Alors, on ruse, on met un fixe ridicule et un gros variable, et au final on gagne plus...

Francois

[souviron34]

Personnellement, je me suis toujours interrogé sur la validité de cette fonction d'architecte. Elle fait bien sur rêver les informaticiens (on "crée" sans jamais avoir à mettre les mains dans les détails dégoutants), mais en pratique, j'ai beaucoup de mal à voir son utilité, sauf à impliquer l'architecte dans la réalisation...

Moi aussi, je me suis toujours interrogé là-dessus..

Comme je l'ai déjà mentionné à X reprises, pour moi une équipe idéale serait d'une part bi-céphale, avec comme Chefs 1 généraliste + utilisateur expert, qui établissent ensemble l'architecture, certains choix techniques (ceux impactant directement l'utilisateur), et d'autre part avec l'équipe en dessous, avec un regard permanent des 2 Chefs..

Je n'ai jamais vu (et j'ai même vu l'opposé) l'intérêt (et la petinence à long terme) d'avoir une belle construction théorique totalement séparée de la réalisation...

Et qui, de plus, est déjà souvent coupée en 2 par "architecte fonctionnel" et "architecte organique"... ce qui est abherrant... mais malheureusement extrêmement courant dans les grosses équipes/projets..

Et j'ai eu (très très malheureusement) à me coltiner de redresser la situation après 10 ans d'interventions d'une telle "équipe"... C'est pas de la tarte...

[el_slapper]

(.../...)
et on répond donc à el_slapper par la même occasion : ton bug de ta banque aurait été très vraisemblablement plus facilement corrigé (et à moindres frais), et SANS regénérer de nouveaux bugs (ni mobiliser toute une équipe pendant 3 ou 5 ans, et donc des ressources considérables) si on avait pris la décision de le corriger plutôt que de tout refaire... Et ton 'impact" sur les utilisateurs sera pire si il faut leur ré-expliquer que ça, qu'ils voient sur leur relevé, ah ben "c'est une erreur de l'info.. Oui, c'est vrai, il y avait déjà eu ce problème il y a 3 ans, mais vous en faites pas, ça va être corrigé le mois prochain"
(.../...)

ça, c'est pour moi.

Le bug, il est apparu sur une maintenance évolutive de la refonte. Refonte que nous avions fait et que nous maitrisions. Serait-elle apparue sur l'ancienne appli, nous aurions été bien embêtes.

Mais cela correspond à un contexte : les auteurs de l'ancienne version étaient dispersés, les auteurs de la refonte étaient destinés à rester longtemps. Ce qui pousse à faire les choses proprement, quand on sait qu'on aura soi-même à ramasser les morceaux.....

Et, dans un cadre général, tu as raison. Quand tous les intervenants, même le chef de projet, sont jetables et externes(ce qui est aujourd'hui le cas général, en ce moment je suis prolongé mois par mois), une refonte est un pont vers la catastrophe, un saut dans le marécage avec les viet-congs qui canardent sans être détectables, pour les raisons que tu as cité.

Dans un cas particuliers ou les auteurs de l'appli sont morts, que leur code est devenu illisible et inmaintenable, que de nombreux bugs sont fossilisés et passent par pertes et profits parcequ'incorrigeables dans l'état actuel des choses, alors une refonte est loin d'être absurde.

[souviron34]

Dans un cas particuliers ou les auteurs de l'appli sont morts, que leur code est devenu illisible et inmaintenable, que de nombreux bugs sont fossilisés et passent par pertes et profits parcequ'incorrigeables dans l'état actuel des choses, alors une refonte est loin d'être absurde.

Nous sommes bien d'accord là-dessus..

Mais ton exemple était dans ce cas plutôt un contre-exemple :

Le bug, il est apparu sur une maintenance évolutive de la refonte. Refonte que nous avions fait et que nous maitrisions. Serait-elle apparue sur l'ancienne appli, nous aurions été bien embêtes.

Qui est bien ce qu'on disait plus haut


Quant au fait de "maitriser'", d'après ce que tu dis c'était plutôt un très très gros bug... Corrigeable certes, mais qui ne serait pas apparu sans la refonte

[Franck SORIANO]

@Franck Soriano

Il y a un problème de fond dans cette démarche dans laquelle on a un architecte qui "conçoit librement", puis un CP qui exécute sous contrainte. Et dans la situation que tu décris, l'architecte porte une lourde responsabilité dans l'échec du projet... Imaginer une "oeuvre d'art" théorique sans prendre en compte la réalité de l'équipe de developpement, c'est totalement irresponsable.

Tu n'as pas bien lu, dans la situation que je décrivais, le projet est un succès !

De plus, je n'ai jamais dit que l'architecte pondait un truc sur-réaliste, détaché de la réalité de l'équipe de développement.
Il ne faut pas grand chose pour massacrer un chef d'oeuvre, tu as un tas de façons d'y parvenir sans qu'il y ait un quelconque problème de compétences.

Un petit exemple concrêt :
Je travaille dans la paie. On me demande de migrer une appli Paradox qui ne monte pas en charge. Afin de la faire tourner avec Oracle et SQL Server.
Après un gros travail, j'arrive à une application qui crée un bulletin de paie en moyenne en 3 secondes (traitement complet de calcul + enregistrement dans la base).
Tout le monde est content, mais le product manager me dit malgré tout que les perfs sont encore insuffisantes pour que la troisième offre prévue soit rentable.

Quelques temps après, un développeur fait une modification dans le calcul du bulletin. Il a besoin de 4 champs dans une table qui en contient 300.
Il ne trouve rien de mieux à faire que de lancer un select * sur la table chaque fois qu'il a besoin de la valeur d'un champ. Comme en plus, il faisait ça dans une boucle pour chaque ligne, il a rajouté 200 select.
Le pire, c'est que le traitement où il intervenait faisait déjà le select qui va bien au début, tout ce qu'il avait à faire c'était d'ajouter les 4 champs dans le select existant !
Les temps de calcul sont passés de 3s à 12s par pure négligence, sans que ça ne lui cause le moindre état d'âme.
Et voilà comment massacrer deux ans de boulôt en 4 lignes de code parce qu'un mec a décidé de ne pas réfléchir a ce qu'il faisait...

Enfin bien évidemment, je décris une situation caricaturale mais qui a le mérite d'être explicite.
Il va de soit que dans un projet bien géré, tout le monde doit travailler ensemble et s'efforcer de comprendre les contraintes et les attentes des autres.
En principe d'ailleurs, c'est bien le rôle du Chef de projet : organiser et gérer les choses pour concilier les demandes et les besoins contradictoires de chaque intervenant.

Personnellement, je me suis toujours interrogé sur la validité de cette fonction d'architecte. Elle fait bien sur rêver les informaticiens (on "crée" sans jamais avoir à mettre les mains dans les détails dégoutants), mais en pratique, j'ai beaucoup de mal à voir son utilité, sauf à impliquer l'architecte dans la réalisation...

En pratique, je n'ai jamais vu d'architecte qui se contente de pondre une architecture sans participer ensuite à sa réalisation.
Et c'est bien le plus frustrant : lorsque tu vois sous tes yeux mêmes des devs qui refusent de coder le truc que tu as prévu parce que ça les fait chier d'écrire trois lignes de code en plus...

[B.AF]

De toutes façons, architecte est un métier trop difficile pour être intéressant. En fait l'architecte, c'est une façon polie de parler du missing link :
Celui qui comprend le besoin, son contexte, ses réalités et qui peut le transposer technologiquement.

Donc, le risque d'erreur est immense, et effectivement, tout le monde ne peut pas prétendre à cela.

De même qu'avoir Jboss n'a jamais facilité le développement d'une application critique à forte complexité métier, comprendre le métier n'a jamais facilité l'apprentissage des fondamentaux.

Faire architecte en 2010, c'est travailler en sous marins constamment en gommant les inefficiences d'une segmentation de l'informatique technocratique de plus en plus grotesque.

Cependant, j'aime mon métier, et je préfére être dans un processus créatif que dans un processus rigoriste. Ne serait-ce que parce que le résultat me parait toujours plus intéressant que les moyens, et que la premiére chose à faire pour concevoir un soft, c'est d'avoir les pieds sur terre, et de n'avoir aucune croyance.

[lepinekong]

Bah tout ça va se terminer par un Leap Jump pour résoudre cette "Crise de la Complexité": Outsourcing et Automatisation en masse comme ce qui s'est produit dans l'Industrie passée (bien sûr les gens à l'époque pensait que c'était des tâches trop compliquées pour être automatisées mais ils avaient tort). UML/MDA/MDE ça n'a jamais bien marché pour l'automatisation et je n'y ai jamais crû, c'est trop compliqué et incomplet pour la pratique de la masse. Mais il est en train de surgir une nouvelle génération de plateforme d'IDE, Générateur de Code et Processus d'Intégration Agile que j'ai entrapercu, les profils requis ne seront plus des architectes, programmeurs mais des business analysts. Bien sûr il y en aura toujours mais le nombre sera drastiquement réduit tout comme l'industrie traditionnelle a réduit les emplois de 50% en une dizaine d'années.

[B.AF]

Bah tout ça va se terminer par un Leap Jump pour résoudre cette "Crise de la Complexité": Outsourcing et Automatisation en masse comme ce qui s'est produit dans l'Industrie passée (bien sûr les gens à l'époque pensait que c'était des tâches trop compliquées pour être automatisées mais ils avaient tort). UML/MDA/MDE ça n'a jamais bien marché pour l'automatisation et je n'y ai jamais crû, c'est trop compliqué et incomplet pour la pratique de la masse. Mais il est en train de surgir une nouvelle génération de plateforme d'IDE, Générateur de Code et Processus d'Intégration Agile que j'ai entrapercu, les profils requis ne seront plus des architectes, programmeurs mais des business analysts. Bien sûr il y en aura toujours mais le nombre sera drastiquement réduit tout comme l'industrie traditionnelle a réduit les emplois de 50% en une dizaine d'années.

Je n'y crois pas à tout ça, ce sont des concepts, on ne peut pas substituer les hommes ni masquer l'absence de compétences.
La génération de code, c'est super, mais bon....C'est sans intelligence
Les leaks, les besoin du multithreading, on le découvre dans le service ou dans la méthode. On ne le découvre pas ex-nihilo en faisant une application. Où alors si : on fait le framework .Net. Ca en fait la partie générale, ça n'enléve pas la spécialisation.
Pire, parfois il faut tout repenser depuis zéro.
Moralité, on se retrouve avec des hordes de développeurs peu motivés, sans réelles compêtences (je ne comprends toujours pas comment développer correctement ce que l'on ne comprend pas, mais bref...), mal payés, parfois prestas. quand il corrige des bugs, personne ne test, personne ne les aide à comprendre si c'est logique, en revanche, il faut corriger sans poser de questins pour sauver les fesses du middle management, et livrer. Processus au terme duquel le dev est toujours coupable.
L'équipe de maintenance elle passe son temps devant un iITS à scruter les nouveaux bugs, qu'elle fixe tant bien que mal dans une niéme branche du produit dont la livraison est en retard de 2 mois.
A côté on trouve des armées de moa, ba, et autres anglicismes qui eux ne comprennent rien à l'architecture, ni au problèmatique de dev mais qui expliquent comme intégrer des processus et font des documents qui ne sont lisibles par eux; n'ont jamais de méthodologie de test fiable, ne sont jamais responsables de rien. Quand on leur pose une question, ils répondent invariablement par le forward de 375 emails, 42 documents et éludent toute profondeur en disant "je ne suis pas dev, les questions techniques je ne comprend pas".
A l'étage du dessous, les admins qui ne jurent que par l'OS, Ubuntu et MySql, beugle sans cesse sur le mauvais usage des outils techniques mais ne comprennent pas à quoi ils servent et plutôt que d'aider, forcémment, ils se plaignent. Quand on leur demande de penser aux modifications à faire, ils répondent "faut demander au dev, c'est eux qui font les cons".

Finalement, c'est en retard, mal baisé, et qui s'y colle ?
Ben c'est simple, le mec qui va prendre son costume, discuter avec le client, puis les autres, rationaliser le truc, penser au re -use, aux contraintes d'implémentation, aux contraintes de données, faire des simulations, qui sont des cas de test en fait, prototyper pour s'éclaircir les idées.
Au passage, il faut naviguer dans toutes les bouzes pondues, et se rendre compte que le dernier à avoir lu la doc "Implémenter une nouvelle x" ...C'est toi, vu que tu l'as modifiée, mais que personne d'autre ne la lie.
Donc, tout est cuit, dérivé, surchargé, et fait à la va vite.
Forcémment, tu te repognes les tests du reste d'une base de test inexistante.

Et toi tu as 15 jours pour faire ça, là où les autres y passent 6 mois.
En provoquant la rage de ceux du dessus, mais la satisfaction du client.

[souviron34]

Moi je prie (comme pour le reste) pour que ça finissse, avec l'économie, par vraiment se casser la gueule, et que ce ne soit pas 50, mais 75% de la profession qui soit à terre..


Peut-être qu'enfin certains finiront-ils par voir "la lumière", et revenir à quelque chose de censé, avec des petites équipes de gens motivés, qui travaillent dans l'"Agile" mais sans quoi que ce soit comme méthode, parce que ce sont de bons artisans qui réfléchissent à ce qu'ils font (tous)... et qui documentent pour des gens comme eux (et pas le zozo qui sort de l'école trucmuche ou l'indien esclave ou le gars sans culture), sans avoir à repartir de zéro à chaque fois, mais en assumant que telle et telle et telle chose est connue, comprise, assimilée, et sans avoir besoin d'outils gros comme une grue pour soulever une feuille de papier...

Avec pour ligne de conduite de faire quelque chose de durable... Et que l'on admette que dans tous les domaines on a fait de la M.rde prodigieuse depuis quelque temps, et que les Romains, ou Egyptiens étaient bien plus forts que nous, avec leurs trucs qui tiennent 2 à 5 000 ans... Alors que nous nos machins ne tiennent même pas 5 ans... (et pour les vraies constructions c'est guère mieux).




Arff.. Je viens de tomber du lit.. ça n'était qu'un rêve

[B.AF]

Moi je prie (comme pour le reste) pour que ça finissse, avec l'économie, par vraiment se casser la gueule, et que ce ne soit pas 50, mais 75% de la profession qui soit à terre..


Peut-être qu'enfin certains finiront-ils par voir "la lumière", et revenir à quelque chose de censé, avec des petites équipes de gens motivés, qui travaillent dans l'"Agile" mais sans quoi que ce soit comme méthode, parce que ce sont de bons artisans qui réfléchissent à ce qu'ils font (tous)... et qui documentent pour des gens comme eux (et pas le zozo qui sort de l'école trucmuche ou l'indien esclave ou le gars sans culture), sans avoir à repartir de zéro à chaque fois, mais en assumant que telle et telle et telle chose est connue, comprise, assimilée, et sans avoir besoin d'outils gros comme une grue pour soulever une feuille de papier...

Avec pour ligne de conduite de faire quelque chose de durable... Et que l'on admette que dans tous les domaines on a fait de la M.rde prodigieuse depuis quelque temps, et que les Romains, ou Egyptiens étaient bien plus forts que nous, avec leurs trucs qui tiennent 2 à 5 000 ans... Alors que nous nos machins ne tiennent même pas 5 ans... (et pour les vraies constructions c'est guère mieux).

Arff.. Je viens de tomber du lit.. ça n'était qu'un rêve

En même temps quand je vois la culture générale moyenne des gens qui m'entourent, je suis pas certain que ce genre de recul soit possible.
Le problème quand même aussi de cela c'est le nombre de fois où la roue est inventée dans l'année.
M'enfin, nous avons bien des ministres qui ne connaissent pas la constitution...

[lepinekong]

Je n'y crois pas à tout ça, ce sont des concepts, on ne peut pas substituer les hommes ni masquer l'absence de compétences.

C'était aussi des concepts dans l'industrie jusqu'à ce que ... quant aux compétences tu crois qu'un pays comme l'Inde avec une tradition de mathématiciens et d'astronome vont en manquer (je mentionne même pas la Chine ), rien qu'à regarder les vidéos de Microsoft j'ai déjà l'impression d'en voir pas mal et pas que grouillot mais chez les managers.

La génération de code, c'est super, mais bon....C'est sans intelligence
Les leaks, les besoin du multithreading, on le découvre dans le service ou dans la méthode. On ne le découvre pas ex-nihilo en faisant une application. Où alors si : on fait le framework .Net. Ca en fait la partie générale, ça n'enléve pas la spécialisation.

Certes mais si c'est pris en charge par les ingénieurs chez Google, Microsoft ou d'autres qui s'y connaissent mieux que quiconque vu que ce sont eux qui conçoivent ça, la spécialisation elle va se faire à un plus haut niveau: le niveau métier.

Pire, parfois il faut tout repenser depuis zéro.
Moralité, on se retrouve avec des hordes de développeurs peu motivés, sans réelles compêtences (je ne comprends toujours pas comment développer correctement ce que l'on ne comprend pas, mais bref...), mal payés, parfois prestas. quand il corrige des bugs, personne ne test, personne ne les aide à comprendre si c'est logique, en revanche, il faut corriger sans poser de questins pour sauver les fesses du middle management, et livrer. Processus au terme duquel le dev est toujours coupable.
L'équipe de maintenance elle passe son temps devant un iITS à scruter les nouveaux bugs, qu'elle fixe tant bien que mal dans une niéme branche du produit dont la livraison est en retard de 2 mois.

Je déplore cet état de taylorisme vu que je suis de l'école de Deming qui est d'agrandir le gâteau et que plus les gens sont motivés plus la qualité et la croissance est là, je ne parle pas de ce que je voudrais, je parle de ce qui va arriver compte tenu que le système n'est absolument pas conçu pour satisfaire le bien-être de la majorité de la population mais pour le profit d'une minorité qui fait fi du gaspillage humain en la rendant peu chère grâce à une mise en concurrence mondiale.

A côté on trouve des armées de moa, ba, et autres anglicismes qui eux ne comprennent rien à l'architecture, ni au problèmatique de dev mais qui expliquent comme intégrer des processus et font des documents qui ne sont lisibles par eux; n'ont jamais de méthodologie de test fiable, ne sont jamais responsables de rien. Quand on leur pose une question, ils répondent invariablement par le forward de 375 emails, 42 documents et éludent toute profondeur en disant "je ne suis pas dev, les questions techniques je ne comprend pas".

Certes mais c'est justement pour ça que je parle de Jump Leap: ils en ont marre d'avoir à des gens techniques qui ne les comprennent pas. Le sens inverse ils le considèrent même pas car c'est toujours l'aval qui tire, pour illustration regardes les supermarchés comment ils écrasent aujourd'hui les fabricants. Je me souviens que j'étais en stage dans une usine de Danone (enfin à l'époque BSN) et que le supermarché d'en face avait copié un de leur produit ils n'ont même pas osé les attaquer par contre ils avaient attaqué Rika Zaraï pour la même raison

A l'étage du dessous, les admins qui ne jurent que par l'OS, Ubuntu et MySql, beugle sans cesse sur le mauvais usage des outils techniques mais ne comprennent pas à quoi ils servent et plutôt que d'aider, forcémment, ils se plaignent. Quand on leur demande de penser aux modifications à faire, ils répondent "faut demander au dev, c'est eux qui font les cons".

Benh les admin c'est comme la dev vis à vis de la MOA

Finalement, c'est en retard, mal baisé, et qui s'y colle ?
Ben c'est simple, le mec qui va prendre son costume, discuter avec le client, puis les autres, rationaliser le truc, penser au re -use, aux contraintes d'implémentation, aux contraintes de données, faire des simulations, qui sont des cas de test en fait, prototyper pour s'éclaircir les idées.
Au passage, il faut naviguer dans toutes les bouzes pondues, et se rendre compte que le dernier à avoir lu la doc "Implémenter une nouvelle x" ...C'est toi, vu que tu l'as modifiée, mais que personne d'autre ne la lie.
Donc, tout est cuit, dérivé, surchargé, et fait à la va vite.
Forcémment, tu te repognes les tests du reste d'une base de test inexistante.
Et toi tu as 15 jours pour faire ça, là où les autres y passent 6 mois.
En provoquant la rage de ceux du dessus, mais la satisfaction du client.

Justement ce que tu décris là je connais, c'est trop le boxon, le métier en a marre, et ce que je dis c'est que je vois des produits et services qui sortent aux US qui ne sont pas encore connus en France et que ça va s'en doute mettre quelques années pour ça mais que c'est autre chose que les usines à gaz russes qu'on voit aujourd'hui autour d'UML ou même de BEPM machin truc parce qu'ils sont absolument pas abordables par un Business Analyst. Certes il faudra toujours 1 expert technique pour des cas tordus mais il en faudra pas 5 ou 10 comme aujourd'hui. Avec la loi de l'inertie ça va mettre 10-15 ans à se répandre dans les mentalités mais c'est sûr que ça répond aux besoins du métier et aux intérêts du Cloud Computing des très gros et même plus petits éditeurs parce que leur schéma business c'est de fournir ces outils sophistiqués gratuitement (ce qui fait que plus personne n'aura tendance à hésiter) et que tu vas déployer sur leur cloud ensuite optionnellement mais tu y seras incité parce que ça sera beaucoup plus intégré et donc beaucoup plus rapide que de passer toutes les barrières de services qu'il y a et bien sûr le coût évidemment est un argument qu'ils avancent.

[Invité]

Les temps de calcul sont passés de 3s à 12s par pure négligence, sans que ça ne lui cause le moindre état d'âme.
Et voilà comment massacrer deux ans de boulôt en 4 lignes de code parce qu'un mec a décidé de ne pas réfléchir a ce qu'il faisait...

J'avoue à avoir du mal avec cet exemple (mais je reconnais ne pas connaitre les logiciels de paye).

Une architecture dans laquelle un gars qui programme avec ses moufles (il y en a quand même pas mal) peut tripler le temps de calcul, et "tuer" la principale promesse de l'application, en une demi ligne de code, est ce bien raisonnable?

Ca manque quand même drolement de robustesse, non?

Et si ce problème est inévitable (je ne crois pas qu'il le soit), ce type de régression ne doit elle pas être prévue et renseignée dans les tests de non régression (je suppose que l'architecte doit au minimum documenter ces tests minimaux, non?)?

Je ne prétends pas avoir la solution à ce problème, et je ne cherche pas à critiquer ce que tu as fait (je ne connais pas le sujet, une fois de plus), mais ça me parait aller dans le sens de mes interrogations sur le bien fondé de cette fonction d'architecte...

Francois

[Franck SORIANO]

Une architecture dans laquelle un gars qui programme avec ses moufles (il y en a quand même pas mal) peut tripler le temps de calcul, et "tuer" la principale promesse de l'application, en une demi ligne de code, est ce bien raisonnable?

C'est vrai que je n'ai pas été très clair. Ce n'est pas une question d'architecture. On m'a demandé de migrer l'appli Paradox existante, pour qu'elle fonctionne à l'identique avec deux SGBD. Le tout avec une grosse contrainte de performance.
Je fais le nécessaire pour atteindre un résultat satisfaisant.

Ensuite la personne qui s'occupe du calcul bulletin doit coder une evo fonctionnelle et ajoute de nouveaux calculs (le calcul d'un bulletin c'est un truc très tordu, qui change tout le temps, avec énormément d'exceptions dans tous les sens).
Sauf que cette dernière considère que son job c'est de faire le nouveau calcul, que les perfs c'est pas son problème et code son truc n'importe comment.
Contre ça, tu ne peux rien faire.

Et si ce problème est inévitable (je ne crois pas qu'il le soit), ce type de régression ne doit elle pas être prévue et renseignée dans les tests de non régression (je suppose que l'architecte doit au minimum documenter ces tests minimaux, non?)?

La dégradation des perfs a bien été détectée au moment des tests. Mais comme elle venait en même temps qu'une evolution lourde dans le calcul, le CP m'a répondu : "c'est normal, c'est ce que le marketing a demandé. Ils ont voulu qu'on monte une usine à gaz, ils ont eu ce qu'ils ont demandé."
Ce n'est que parce que je n'ai pas supporté de voir mon travail massacré de la sorte en une seule évolution que je n'ai pas voulu prendre le CP au sérieux et je suis aller regarder ce qui pouvait justifier une telle dégradation des perfs. Et je vous ai déjà dit ce que j'ai trouvé (en moins de 15 minutes d'ailleurs).

...mais ça me parait aller dans le sens de mes interrogations sur le bien fondé de cette fonction d'architecte...

J'aurrais plutôt tendance à penser le contraire. On me dit (le responsable R&D) que ce genre de couac est normal, qu'un développeur ne peut pas à la fois développer son évolution et faire un code performant. Que ça dépasse les compétences normales d'un développeurs.
Donc si un développeur ne peut pas concilier les deux, il faut bien qu'il y ait une personne qui ait la capacité d'aborder tous les problèmes dans leur ensemble et d'imaginer une solution qui respecte toutes les contraintes !

Ensuite, pour ce qui est de dire que l'architecte laisse les autres mettre les mains dans le camboui, c'est plus discutable.
Je pense que c'est plutôt que l'architecte devant avoir un niveau de compétence plus élevé, il réclame aussi un salaire beaucoup plus élevé. Et lorsqu'on lui demande de faire le travail qu'un développeur lambda pourrait faire, ça parait comme du gaspillage.
Mais personnellement, je me bats pour coder moi même les solutions que j'ai imaginées.

[souviron34]

Je pense que c'est plutôt que l'architecte devant avoir un niveau de compétence plus élevé, il réclame aussi un salaire beaucoup plus élevé. Et lorsqu'on lui demande de faire le travail qu'un développeur lambda pourrait faire, ça parait comme du gaspillage.

ben nous y voilà

Parce qu'un architecte se considère comme "à part", et que l'industrie et les architectes (et CP) en général considère(nt) les "codeurs" comme simplement des pisseurs de lignes.. d'où éventuellement délocalisation..

Faut pas vous plaindre, vous le cherchez..

(peut-être pas toi, d'après ce que tu dis, mais ta "profession" et l'industrie en général)..

[Invité]

Sauf que cette dernière considère que son job c'est de faire le nouveau calcul, que les perfs c'est pas son problème et code son truc n'importe comment.
Contre ça, tu ne peux rien faire.

Là je suis d'accord. C'est un peu pour ça que je me méfie de ces séparations des tâches. J'ai connu des boites (pourtant pas très grosses) où l'on passait bien plus de temps à se renvoyer des compte rendus de bugs à la figure qu'à essayer de les reproduire, voire de les corriger...

J'aurrais plutôt tendance à penser le contraire. On me dit (le responsable R&D) que ce genre de couac est normal, qu'un développeur ne peut pas à la fois développer son évolution et faire un code performant. Que ça dépasse les compétences normales d'un développeurs.

C'est ca que je conteste. Une performance minimale est au moins aussi importante qu'un code correct. Qu'un responsable R&D puisse tenir ce genre de propos me sidère (mais moi, ca me va bien, ma boite fait son beurre parce qu'il y a des gens comme eux).

Donc si un développeur ne peut pas concilier les deux, il faut bien qu'il y ait une personne qui ait la capacité d'aborder tous les problèmes dans leur ensemble et d'imaginer une solution qui respecte toutes les contraintes !

Oui, mais dans la mesure où cette personne peut écrire son code (tu disais que tu as très vite débugué le problème du développeur), ne faudrait il pas remplacer 10 développeurs à moufles par 3 architectes programmeurs? ou si on ne peut faire autrement, aller chercher des développeurs dans les pays chauds, où les salaires sont plus bas, et où l'on ne met pas de moufles?

Et lorsqu'on lui demande de faire le travail qu'un développeur lambda pourrait faire, ça parait comme du gaspillage.

On peut se poser la question... C'est sur qu'à lignes de code égales, tu coutes plus cher que le dev de base, mais si ton code évolue naturellement, ne demande pas de débug, n'a pas besoin d'être "optimisé pour la vitesse" (ce qui signifie généralement qu'il tourne dans un temps raisonnable), économise le salaire, les charges, l'espace de bureau (et l'achat de moufles) d'un dev de base, ca peut se discuter.

Maintenant, si l'effectif sous les ordres du responsable R&D est ainsi réduit, son pouvoir l'est aussi, ...

Francois

[el_slapper]

(.../...)
Justement ce que tu décris là je connais, c'est trop le boxon, le métier en a marre, et ce que je dis c'est que je vois des produits et services qui sortent aux US qui ne sont pas encore connus en France et que ça va s'en doute mettre quelques années pour ça mais que c'est autre chose que les usines à gaz russes qu'on voit aujourd'hui autour d'UML ou même de BEPM machin truc parce qu'ils sont absolument pas abordables par un Business Analyst. Certes il faudra toujours 1 expert technique pour des cas tordus mais il en faudra pas 5 ou 10 comme aujourd'hui. Avec la loi de l'inertie ça va mettre 10-15 ans à se répandre dans les mentalités mais c'est sûr que ça répond aux besoins du métier et aux intérêts du Cloud Computing des très gros et même plus petits éditeurs parce que leur schéma business c'est de fournir ces outils sophistiqués gratuitement (ce qui fait que plus personne n'aura tendance à hésiter) et que tu vas déployer sur leur cloud ensuite optionnellement mais tu y seras incité parce que ça sera beaucoup plus intégré et donc beaucoup plus rapide que de passer toutes les barrières de services qu'il y a et bien sûr le coût évidemment est un argument qu'ils avancent.

Venant moi-même du monde industriel, je vois quand même une différence flagrante : le produit logiciel est immatériel. Ce qui signifie que la demande(comme l'offre) peuvent aller de manière exponentielle, bien plus que les produits industriels. Peut-être est-il possible d'industrialiser le processus de création logiciel(je n'y crois pas beaucoup, mais après tout, pourquoi pas?), mais celà va créer un appel d'air et une demande de traitements encore bien plus forte. D'ou un besoin constant de professionels, même en période de forte croissance de la productivité.

[Franck SORIANO]

Parce qu'un architecte se considère comme "à part", et que l'industrie et les architectes (et CP) en général considère(nt) les "codeurs" comme simplement des pisseurs de lignes.. d'où éventuellement délocalisation..

Faut pas vous plaindre, vous le cherchez..

Et tu voudrais faire comment ?
Dans l'informatique, il y a d'énormes différences de compétences d'un individu à l'autre. Entre le débutant fraichement sorti de l'école et l'expert expérimenté il y a qu'en même un gouffre !

Si tu mets tout le monde dans le même panier, tu fais un nivellement par le bas. L'expert s'ennuie, a le sentiment de perdre son temps et ira voir ailleurs. Le débutant s'imagine qu'il vaut largement l'expert et n'en fait qu'à sa tête. Tu as une armée de débutant qui veulent appliquer la solution de facilité, l'expert est le seul à voir que les conséquences à long termes seront catastrophiques, mais comme on a mis tout le monde au même niveau, on finit par un vote à la majorité et une cata à la fin...

Ou alors tu acceptes que tout le monde n'a pas les mêmes compétences et tu essaies d'organiser les choses au mieux pour tirer le meilleur de chacun. Et tant que tu y es tu essaies de faire en sorte que les débutants apprennent aux contacts des gens plus expérimentés.

Oui, mais dans la mesure où cette personne peut écrire son code (tu disais que tu as très vite débugué le problème du développeur), ne faudrait il pas remplacer 10 développeurs à moufles par 3 architectes programmeurs? ou si on ne peut faire autrement, aller chercher des développeurs dans les pays chauds, où les salaires sont plus bas, et où l'on ne met pas de moufles?

Ca c'est la belle théorie.
Mais dans la pratique, on sait très bien que le problème est plus compliqué. La réussite d'un projet ne dépend pas que de la technique.

Il faut aussi des gens plus orientés côté fonctionnel (personnellement, je ne sais pas calculer un bulletin à la main). En général les experts techniques s'intéressent assez peu au fonctionnel et vis-versa.
Ajoute à ça le fait que tu ne choisis pas toujours ton équipe de développement, et qu'avant d'être doué techniquement il a bien fallu débuter un jour...

[lepinekong]

Venant moi-même du monde industriel, je vois quand même une différence flagrante : le produit logiciel est immatériel. Ce qui signifie que la demande(comme l'offre) peuvent aller de manière exponentielle, bien plus que les produits industriels. Peut-être est-il possible d'industrialiser le processus de création logiciel(je n'y crois pas beaucoup, mais après tout, pourquoi pas?), mais celà va créer un appel d'air et une demande de traitements encore bien plus forte. D'ou un besoin constant de professionels, même en période de forte croissance de la productivité.

Ce n'est pas l'objectif déclaré du cloud que ce soit dans la bouche de Mac Nelly PDG de SUN ou les conséquences sur l'emploi du cloud computing prédit par les cabinets du domaine dans 10 ans: le métier de programmeur n'aura plus lieu d'être - enfin en exagérant il y a toujours des ouvriers dans l'industrie mais beaucoup moins qu'avant et l'emploi y est très précaire. Ils prédisent des emplois surtout de support help desk ou d'infrastructure.

En attendant les programmeurs ont encore quelques belles années devant eux je pense mais il faut voir un peu plus loin compte tenu qu'il faut tenir jusqu'à 60/65 ans

[Emmanuel Deloget]

Sur les codeurs et les architectes

Je suis architecte logiciel, mais bon, il fut un temps ou j'étais considéré comme un simple codeur. Mais tout comme il y a des bons et des mauvais chasseurs, avec tout ce que ça implique comme difficulté pour reconnaitre lequel est le bon et lequel est le mauvais, il y a aussi des bons et des mauvais codeurs. Un bon codeur n'est différent d'un bon architecte logiciel que de par l'étendue de ses connaissance - donc, son expérience. Son code sera propre, évoluera aisément, et aura des performances décentes. Pour être franc, je me surprend des fois à régresser : mon code est bien souvent moins lisible qu'il y a quelques années (parce qu'il fait la part belle à des technologies que je ne devrais pas employer). Ca me va, mais je ne travaille pas tout seul - et un jour, il faudra bien que quelqu'un d'autre que moi lise ce code...

Il faut être honnête : nous faisons un travail de fainéant. Le fond même de notre travail est d'autoriser le monde à être encore plus fainéant. Nous y arrivons en simplifiant les manipulations qu'un tiers dois faire en lui fournissant un logiciel adapté à ses besoins. C'est la même chose pour nous : nous cherchons sans arrêt à limiter notre charge de travail avec des artifices techniques (scripts de génération) ou liés au processus (gestion de configuration, tests automatisés, ...). Nous cherchons avant tout à faire ce que nous considérons comme le minimum vital pour obtenir le résultat recherché. Dans ce cadre, il ne faut pas s'étonner de voir des collègues faire ce qui est à leur yeux le minimum vital - qui nous choque parce que nous, nous aurions forcément fait mieux. D'ailleurs, on fait toujours mieux que son voisin de table : nos bugs sont des bugs moins graves, notre code est toujours plus lisible, il est toujours plus efficace, etc. A partir de là, il ne faut même pas chercher à se demander pourquoi notre voisin de table ne fait pas plus attention à la qualité de son travail - après tout, il a tout à fait le droit de penser la même chose que nous...

Sur les compétences normales d'un développeur

Ben oui, un développeur typique à un set de compétence typique. C'est le pragmatisme qui l'enseigne. Dans le monde idéal, un développeur sait programmer dans plusieurs langages, a une vision englobante de sa tâche, est capable d'écrire du code propre avec un minimum de bugs. Il sait aussi lire le code des autres et le cas échéant le débugger. Il sait s'adapter à une nouvelle technologie ou à un nouveau métier (passer du bancaire à la photographie par exemple). Tout ça, c'est bien beau - mais dans la pratique, un développeur lambda :

• Ne connait qu'une seul et unique langage de programmation, et bien souvent il le connait imparfaitement. Bien souvent, certaines subtilités lui échappe. Il n'est pas rare de rencontrer un programmeur Java qui sait qu'il faut utiliser .equals() pour comparer deux chaines de caractère, mais qui ne sait pas vraiment pourquoi c'est nécessaire (autrement que "parce que == ça marche pas").
• A bien du mal à relire son propre code, parce qu'il est bien souvent écrit sans véritable réflexion. Heureusement, les IDE modernes aident à la mise en page du code avec une indentation complètement automatique.
• A énormément de mal à relire et comprendre le code de ses collègues (principalement parce que ses collègues sont comme lui).
• A des difficultés énorme à intégrer une nouvelle technologie.
• A des difficultés énorme à comprendre les enjeux d'un métier particulier, et aura du mal à faire la transition vers un métier nouveau.
• N'a qu'une vision partielle du travail qu'il doit effectuer et de la façon dont ce travail s'inscrit dans le projet en cours. Notez que ce problème récurrent est quelques fois lié à la structure du projet lui même (on ne va pas demander à l'équipe responsable de l'écriture de MS Paint de comprendre les tenants et les aboutissants du système qui virtualise la mémoire des cartes graphique dans Windows Vista) ou au contraire lié au management projet, qui souhaite compartimenter le développement au maximum - souvent à tort, car la compartimentation (sic) enferme les développeurs dans une spécialisation dont il est difficile de les faire sortir tout en augmentant le risque lié à la défection d'un élément critique dans l'équipe (puisque le nombre d'éléments critiques augmente de fait).
• Se croit doué quand même, et le montre en plaisantant dans le code - avec des noms de fonction comme SauceGrandVeneur(). Si, je l'ai déjà vu.

Je conçoit que c'est un peu pessimiste comme vision, mais après avoir travaillé une dizaine d'année dans différents secteurs, c'est hélas le constat que je fait. Le développeur lambda ne s'intéresse à l'informatique que parce que c'est son métier - il ne visite pas ce site web (à moins qu'il soit bloqué par un problème), il ne cherche pas à s'intéresser à de nouvelles technologies lorsqu'il a du temps libre, il ne programme pas en dehors des heures d'ouverture de son bureau, etc. Ce n'est pas pour autant un mauvais développeur - c'est un développeur lambda.

En résumé, il vit son métier comme il est logique de vivre son métier - pour paraphraser Molière, il faut travailler pour vivre, et non pas vivre pour travailler.

Ce programmeur là aura peut-être du mal à devenir chef de projet ou à obtenir des responsabilités sur un ou plusieurs projets, mais vu qu'après plusieurs années à faire les mêmes choses il est tout à fait compétent dans son métier, il y a quand même de bonnes chances qu'il y accède. Le manque de qualité supposé de son travail de programmeur n'a que peu d'influence sur son métier de chef de projet - puisqu'il pourra s'appuyer sur une batterie de programmeurs pour faire le travail technique.

Sur le Cloud Computing

Ce n'est pas l'objectif déclaré du cloud que ce soit dans la bouche de Mac Nelly PDG de SUN ou les conséquences sur l'emploi du cloud computing prédit par les cabinets du domaine dans 10 ans: le métier de programmeur n'aura plus lieu d'être - enfin en exagérant il y a toujours des ouvriers dans l'industrie mais beaucoup moins qu'avant et l'emploi y est très précaire. Ils prédisent des emplois surtout de support help desk ou d'infrastructure.

En attendant les programmeurs ont encore quelques belles années devant eux je pense mais il faut voir un peu plus loin compte tenu qu'il faut tenir jusqu'à 60/65 ans

Il est assez incroyable qu'encore à notre époque des dirigeants de grandes sociétés informatique continuent de dire qu'un jour, le métier de programmeur sera has been - étant donné que c'est ce métier de programmeur qui leur permet de vendre des machines, c'est en plus un contresens au niveau business. Pire encore, prétendre vouloir remplacer les programmeurs par des métiers métant en avant que les logiciels sont mal conçus et difficiles à utiliser (d'où un besoin accru de help desk), c'est vraiment tout faire pour se tirer une balle dans le pied.

Le cloud computing génèrera du travail pour les programmeurs. Les logiciels qui vont supporter cette architecture ne vont pas s'écrire tout seul. Ils ne vont pas évoluer tout seul. Et je doute que les équipes qui vont les écrire seront plus petites que les équipes actuelles.

Cabinets d'analyse. En voilà un joli business. Tant que les "prédictions" de ces cabinets sont à court terme, ils arrivent globalement à être à peu près juste (et encore : ils n'ont pas été capable de prévoir l'effondrement du marché de la photo argentique, par exemple, alors que celui-ci a été très rapide. Ils n'ont pas non plus été en mesure d'annoncer l'explosion du téléchargement illégal, alors que tous les signes étaient là. Eut-il été annoncé plus tôt, je peux vous assurer que les majors auraient probablement changé de stratégie plus tôt). Dès qu'ils s'essaient à des prévisions à long terme (10 ans pour l'informatique, c'est quand même très long), ils ont une tendance nette à se tromper avec une violence rare. En même temps, dire à des sociétés qui en font une stratégie à moyen-long terme que le cloud, ça ne marchera pas (et j'aurais tendance à dire que ça ne marchera pas), ça n'est pas très vendeur.

Le cloud computing a quand même quelques problèmes.

• Premièrement, rien n'indique qu'il est moins cher à utiliser qu'une architecture traditionnelle (moins cher à la mise en place, mais plus cher à l'utilisation : c'est ce qui ressort actuellement).
• Deuxièmement, rien n'indique non plus que son niveau de spécialisation sera assez fort pour que les entreprises lui fasse confiance. Si utiliser des applications en CC me fait perdre le bénéfice d'applications spécialisée et ciblant mon métier, que intérêt ? C'est même un retour en arrière qui n'a pas vraiment de sens au niveau business.
• Troisièmement, je dois quand même faire confiance à un tiers pour tout ce qui est du traitement de mes données et des mes applications. Je ne suis plus maitre de ma configuration logicielle de travail (si mon provider décide de ne plus supporter la version de telle ou telle application dont j'ai absolument besoin, hop, je l'ai dans l'os). Je ne suis plus maître de la sécurité et de la confidentialité de mes données (les accords signés entre mon provider et les gouvernement des différents pays peuvent prévaloir sur la confidentialité de mes informations, notamment si je travaille dans un secteur sensible).
• Quatrièmement, impossible d'avoir un avantage concurrentiel grâce à mes outils informatique. Si toute mon infrastructure est externalisée, je n'ai plus la possibilité d'avoir un système qui a été développé spécialement pour moi et qui pourrait potentiellement m'offrir un avantage concurrentiel énorme. Si j'ai ce système sur une infrastructure CC publique, alors mes concurrent aussi et je perd cet avantage concurrentiel.

Le Cloud Computing peut avoir un intérêt, mais aujourd'hui j'ai bien du mal à voir lequel. Ca demande beaucoup de dépenses, ça coute cher dans le long terme, et ça n'apporte rien puisqu'il faut continuer à maintenir des couts de license prohibitifs et des systèmes lourds en interne pour avoir accès aux applications maison. Ceci dit, à budget élevé, prime élevée une fois que le projet a été mené à bien...

[souviron34]

Un grand merci pour cette contribution constructive, bien écrite, pensée, construite, et argumentée..