Discussion :

[psykokarl]

Je vais juste mettre le doigt sur une notion très confuse dans le monde de l'informatique à savoir l'industrialisation.

L'industrialisation vise à améliorer la productivité et la baisse des couts. On est pas dans le qualitatif sauf pour ce qu'il entre en jeu dans la définition de ce qu'est un produit fini.

Une fois cette notion bien comprise, on peut disserter à loisir de l'écart entre les méthodes industrielles et de leur application in situ.

Cela reste vrai pour le bâtiment, pour l'informatique, pour l'horticulture et pour les fabriques d'harmonica...

[Canard34]

mouais mouais....
un peu trop facile la métaphore à 2 balles

On construit un building avec des capacités maximales et avec un cahier des charges très précis.

et on devrait construire un logiciel dans ces mêmes caractéristiques.

Sauf que dans la plupart des cas, on s'autorise à pousser les limites du logiciel, à faire des modifications qui sortent du cahier des charges initiales et qu'a la fin, donne à une belle usine à gaz(qui a souvent le merite de fonctionner ;-) )

Je veux juste dire, que si on mettais les mêmes contraintes de ce que subissent les logiciels en général dans leur durée de vie sur les immeubles, et bien y'en à beaucoup qui tomberaient.
Un immeuble par exemple n'est pas fait pour subir un avion de pleins fouet.
Un logiciel par exemple n'est pas fait(a l'origine) pour subir une attaque DOS

c'est bien beau, mais la comparaison entre logiciel et building ou software et immeuble à tout simplement rien à voir.

Je ne suis qu'un modeste et mauvaise développeur qui à le mérite de faire des applications métiers qui fonctionne depuis des années et qui n'a pas ruiné mon entreprise.

En même temps, ça me déplait pas d'être jardiner ;-)

mais peut être que je suis hors sujet
Bonne après midi à tous.

Canard34 - Jardiner d'application / Jardinier système depuis 1990

[hegros]

[hs]

Je ne vois pas le rapport entre le paradigme objet et un processus de facturation.

Justement il n'y en a pas

Par ailleurs, si ce ne sont pas des objets dans UML, je ne vois pas ce que représentes les fameux carrés jaunes!

Des entités ou des concepts. Cependant tu te limites là exclusivement au diagramme de classe en faisant fi des 8 autres.

[/hs]

[benzoben]

Des entités ou des concepts. Cependant tu te limites là exclusivement au diagramme de classe en faisant fi des 8 autres.

Pour moi quand je parle d'UML, objet = entité = concept.

[hegros]

Pour moi quand je parle d'UML, objet = entité = concept.

Encore du chipotage mais ce ne sont pas des objets mais des classes et tu es mal barré si tu dois faire une implémentation avec un langage non objet

[benzoben]

???

[scalino]

mis à part le fait que son analogie ne peut pas être un morphisme, tout simplement parce que la modélisation d'un processus métier et les applications qui l'implémentent n'ont que très peu de choses en commun avec la nature et les végétaux qui la composent, son analyse est surtout extrêmement caricaturale que ce soit pour l'informatique ou pour le bâtiment.

Ce qu'il y manque essentiellement c'est la prise en compte des "spécifications", nom d'un p'tit transistor quantique !

Pour les spécifications d'un immeuble, mis à part quelques détails, le cahier des charges a été établi depuis un bon moment... En ce qui me concerne (et j'imagine que c'est la même chose pour beaucoup d'entre nous) le cahier des charges, je dois l'inventer tous les jours ou presque...!

De ce fait, ce môssieur fait un amalgame largement éhonté entre "l'ingénieur théorique du génie civil" capable de tout prévoir a priori (qu'on me l'amène lui, j'aimerais bien le rencontrer...) et le "développeur en pratique" qui - bien souvent - est à la fois: l'ingénieur, le médiateur (vis-à-vis du client profane), le rédacteur du cahier des charges, l'analyste, l'ergonome, le programmeur, le beta-testeur, et le dépanneur de niveau 2... (si vous voyez ce que j'veux dire...)

A bon entendeur salut,

et je ne vous salue pas, môssieur... :p

Scalino

[sethlegoauld]

Les ingénieurs seraient, quant à eux, capables de prédire et concevoir, dans le moindre détail, les délais de réalisation et la forme du moindre recoin d'un futur gratte-ciel, avec un taux élevé de succès dans leurs prédictions.

Ah ah la bonne blague... on voit qu'il n'a jamais eu affaire aux ingenieurs en genie civil au Quebec le mossieur


Je rajouterais quand meme que l'ingenieur informaticien ne sait exactement ou il va, tout simplement parce que son client non plus et que ledit client (certains en tout cas) change son cahier des charges toutes les semaines

[ctxnop]

Je rajouterais quand meme que l'ingenieur informaticien ne sait exactement ou il va, tout simplement parce que son client non plus et que ledit client (certains en tout cas) change son cahier des charges toutes les semaines

Seulement ? Hann la chance, chez nous ca a plutôt tendance a changer deux fois par jours...

[id6tems]

D apres des statistiques l ingenieur passe entre 40% a 60% de temps dans la planification, et le reste dans le cote technique; et bien sur il est ingenieur par son cote plannificateur;
Le developpeur quant a lui, son travail meme, son produit, et le but de sa disciplin c st de plannifier un travail, quel qu il soit; le developpeur n est ni architecte ni avocat ni boulanger, et pourtant il peut faire un programme pour l architecte, un autre pour l avocat, et un autre pour le boulanger, et un autre pour l entraineur d une equipe de sport...

Et donc le developpeur est l ingenieur par excellence, et qui de surcroit, se doit d etre pluridisciplinaire et encyclopediste;

Mais apres tout, les noms... l important comme dirait gilbert becaut c est la rose, et la rose c est la participation a l evolution des sciences dans tous les domaines; car toutes les sciences ont besoin de toutes les sciences pour evoluer; et chacun fait d son mieux la ou il est...

[bugsan]

Le partie construction ca revient à implémenter dans un langage un algorithme dont on a le pseudo code. Globalement, on sait combien de temps ca va nous prendre, la qualité finale, etc... Et ca n'empêche pas quelques mal façon.

Le problème semble + fondamental. Le simple fait d'imaginer une phase conception et une phase construction, est une erreur à mon avis. Et c'est encore plus catastrophique lorsqu'on attribut ces deux taches à des gens différents (pertes d'information au passage).

On a voulu projeter le modèle industriel au développement logiciel. De ce fait, on peut expliquer beaucoup de choses :

• Les "codeurs" étant le parallèle des ouvriers, on les a mis de toute évidence en bas de l'échelle. Les architectes qui ne codent pas, tout en haut dans leur ivory tower.
  L'écriture du code n'étant pas de la conception, on a pensé qu'il n'y avait pas besoin de compétence pour le faire (pas besoin de cursus IT).

Et les outils de modélisation comme UML n'ont pas aidé. Ils ont permis de justifier cette pseudo séparation conception/réalisation.

Il est vraiment temps de remettre le code source au centre du projet.

[Luckyluke34]

Le problème semble + fondamental. Le simple fait d'imaginer une phase conception et une phase construction, est une erreur à mon avis. Et c'est encore plus catastrophique lorsqu'on attribut ces deux taches à des gens différents (pertes d'information au passage).

On a voulu projeter le modèle industriel au développement logiciel. De ce fait, on peut expliquer beaucoup de choses :

• Les "codeurs" étant le parallèle des ouvriers, on les a mis de toute évidence en bas de l'échelle. Les architectes qui ne codent pas, tout en haut dans leur ivory tower.

Tout à fait d'accord.

L'écriture du code n'étant pas de la conception, on a pensé qu'il n'y avait pas besoin de compétence pour le faire (pas besoin de cursus IT).

Au contraire, l'écriture du code, c'est de la conception en permanence. Ce sont des décisions de design à prendre à chaque instant. En tant que développeur, on passe notre temps à concevoir de vrais petits systèmes : graphes de classes et leurs dépendances, méthodes/fonctions, algorithmes, tests unitaires... et parfois de plus gros : modules, couches applicatives, architectures entières...

Il est vraiment temps de remettre le code source au centre du projet.

[Blaise]

Bonsoir,

Entre bâtir un gratte-ciel et un jardin, il y a de nombreuses et grosses nuances.

Un (seul) ingénieur ne suffit pas pour bâtir un gratte-ciel, tandis que pour jardiner...
Les risques de rater un gratte-ciel sont autrement plus conséquents que le mildiou.

Changez "ingénieur es-gratte-ciel" par "ingénieur-paysagiste" qui demande au jardinier combien de temps il lui faudra pour planter une route de laitues avec 100 % de succès !

Le (bon) jardinier va réussir, mais il va passer au moins une fois par jour sur la route, sans savoir combien de fois au minimum il va devoir y repasser.
Et il va demander des réserves et du temps souvent bien plus que nécessaire. Peu importe pourvu que le résultat soit là.

Sans compter les facteurs extérieurs comme le bon fonctionnement de ses outils, de la pluie ou tout simplement l'accès au jardin. Traduisez un PC uptodate , de la disponibilité des infos extérieures et un réseau fonctionnel.

Merci de m'avoir lu, Blaise

[bugsan]

Au contraire, l'écriture du code, c'est de la conception en permanence. Ce sont des décisions de design à prendre à chaque instant. En tant que développeur, on passe notre temps à concevoir de vrais petits systèmes : graphes de classes et leurs dépendances, méthodes/fonctions, algorithmes, tests unitaires... et parfois de plus gros : modules, couches applicatives, architectures entières...

Je suis bien d'accord ^^ j'étais dans l'ironie. Je me plaçais dans la tête des managers : "puisque coder c'est construire, donc pas de conception à faire, donc pas de compétence nécessaire, donc grouillot ..."

[nonpoluant]

Je suis développeur et je suis d'accord avec l'article. Mais il y a une façon beaucoup plus simple (et pertinente il me semble) de le dire :

Tous les domaine d'ingénieries se basent en théorie sur des modèles mathématiques. Sauf le dev !

Les développeur se basent juste sur des process, plus ou moins bien éprouvés, plus ou moins conçu de façon empirique, c'est de la cuisine quoi, on suit une recette qui a l'air d'être pas mal.

Mais ce n'est pas une fatalité, je pense que rien n'empêche au développement informatique de devenir une science de l'ingénieur, basé sur des modèles mathématiques, il faut juste un changement de mentalité.

C'est déjà un peu le cas dans le domaine de l'algorithmie, où là on utilise des vrais math pour prouver leur correction, leur efficacité, et les concevoir.
Mais ça se fait toujours attendre dans le domaine de l'architecture logicielle etc... (bien qu'il existe déjà des méthodes formelles dans ce domaine, elles ne sont pas suffisamment utilisées)

[MeTaLCaM]

Je la trouve surtout arrogante et méprisante envers les développeurs. Le message véhiculé est claire, voire carrément explicite à la fin : "les développeurs, c'est nul et les ingénieurs, c'est bien". Est-ce parce que la culture d'entreprise de Facebook serait axée ingénieurs et que Google songerait à faire la même chose que ce genre de déclaration sort au grand jour ?

J'aurai plutôt utilisé une analogie avec la musique. Le développeur musicien doit commencer par apprendre son solfège (algorithmique) et savoir jouer d'au moins un instrument (langage de programmation). Ses mélodies (programmes) sont plus ou moins réussis selon le rythme (architecture du programme) et certains arrivent à y caser de jolis accords parfaits (design patterns) ou des beaux canards (bugs).

L'ingénieur (chef de projet ?) serait alors le chef d'orchestre car il a une vision globale sur tout son orchestre (pool de développeurs) et le dirige. Il ne sait (peut ?) pas (ou plus) jouer d'un instrument dans le cadre de son travail.

Etant moi-même musicien et développeur, je trouve la comparaison vraiment amusante (et correcte !).

[Charvin]

Je comprends bien ce qu'il peut y avoir de vexant à se voir retirer le titre d'ingénieur (je suis moi même ingénieur) mais le fond de l'article n'est pas là.

Ce que cherche à faire l'auteur, c'est à mettre en évidence les différences qu'il y a entre la construction d'un gratte-ciel et le développement d'un logiciel. Ces différences sont grandes et pourtant les méthodologies de gestion de projets utilisées en informatique sont directement inspirées de celles du génie civil.

La comparaison d'un développeur avec un jardinier n'est peut-être pas la plus pertinente, mais ses réflexions sur les différences entre la construction d'un gratte-ciel et le développement d'un logiciel sont elles très intéressantes (il faut lire l'article original)...

[frederic.bouchery]

Je ne vois rien de dégradant ou provocateur là dedans !?
Trouver ça dégradant revient à dire qu'un jardinier, c'est un boulot "nase" pour ceux qui on rater leur vie.

Non, ici on ne compare pas les hommes, mais le travail en lui même.

Ceux qui ne sont pas d'accord avec la métaphore sont des développeurs qui travaillent sur des projets avec un bon niveau de ré-utilisation. Ils sont donc en mesure de prédire le périmètre et la charge avec un très haut niveau de confiance.

A l'inverse, ceux qui traitent des projets très différents les uns des autres et qui ne peuvent pas (ou peu) faire de la ré-utilisation, se voient parfaitement en jardinier : ils découvrent au fur et à mesure les problèmes, et ne sont pas toujours en mesure de savoir ce qu'ils vont rencontrer tant qu'ils n'auront pas soulevés le drap.

Cela fait longtemps que le terme "être informaticien" ne veut plus rien dire en dehors du seul point commun : "utilise un ordinateur pour travailler" (ex: DBA, architecte système, IT, webmaster, développeur mobile, etc.).
Désormais, "être développeur" n'est plus assez précis, car il existe bien trop de différences entre eux, que ce soit dans la techno, le secteur d'activité, le support, etc.

Par exemple, chez les militaires, ou dans certaines web-agency spécialisées, on est plus des bâtisseurs et dans la R&D/Innovation, on est plus dans le jardinage.

Donc, pour moi, la métaphore est valable pour certains contextes et pas pour d'autres. Dans mon cas .... heu ... je suis un jardinier, et j'en suis fier.

[ikarus]

"Chris Aitchison, un blogueur développeur australien " <= Il est développeur et ne fait pas de conception et ne prévoit pas l'avenir de ses applications ?

Wouhaaahouuu je montrais jamais une boite en Australie !

[maheffa32]

Combien de gens visitent le tour Eiffel depuis son construction, et combien de gens utilisent le petit script/logiciel de chat sur facebook en une anne ? euh ... et ... le secteur du genie civil c'est classe ou dans , euh .. par exemple .. forbes magazine, par rapport au secteur informatique ? euh ... et ... qu est ce qui est plus difficile ? elaborer un plan a partir des lois physiques connus depuis 3 siecles ou bien gerer le fonctionnement d'un base de donne des millions d'utilisateurs (banque, social network, compagnie telephonique, agence de voyage ... etc ... ) ? sans qu'aucun d entre eux ne se confondent, que l'algorithme d rechereche soit optimal, qu'l n y aurais aucun retard dans la requette ? ..etc... et la vie qui commence a s'informatiser partout, les pirates qui en profitent au moindres erreurs des programmeurs, ... hum ... ca vaut meme pas le coup de comparer ingenieur BTP et programmeur (desole mais je defend ma race)