Discussion :

[lod101]

La construction d'un gratte est également soumis à des obstacles et des imprévus (genre la météo, le retard de livraison du métériel, un ouvrier à remplacer car il s'est casséla gueule en tombant d'un échafaudage, et j'en passe).

"Obstacles et imprévus" d'accord, mais pas pour les raisons que tu cites:
- la météo n'est pas un pb dans le génie civil (hormis catastrophes naturelles bien sûr), et les "ingénieurs" du batiment maitrisent ces contraintes.
- Retard de livraison ? Ouais, peut être...
- Un ouvrier qui se casse la gueule ? Je n'espère pas qu'a lui tout seul il remette en cause la construction d'un gratte ciel ou même qu'il est est une influence sur le délai de livraison...

Pour moi les obstacles et imprévus seraient plutot d'ordre politique, financier ou écologique

Coté dev, à quoi sert toute la phase d'analyse si ce n'est de prédire ce que va faire le soft, a quoi sert de faire des diagramme UML si ce n'est pas concevoir en détail, etc. Bref, arguments irrecevables.

Tu es bien catégorique dans ton jugement !!! L'expérience montre bien qu'on a jamais encore vu un soft faire exactement ce qui était prévu en phase de spec et de conception.

...Pour un jardin, on peux aisément creuse dans le sol et remplir avec une terre plus apdte au jardinage, on peux construire une serre.

Illustration parfaite du développement logiciel (tu livres un soft avec une grosse verrue). Le client te demande les jardins Versailles, toi tu lui livre le jardin mais avec une grosse serre par dessus...Y va être content Louis XIV...

On a pas besoin d'un permis de construire pour chaque construction, cela dépend entre autre de la surface. Coté dev, un mec qui developpe son petit solf dans son coin pour gérer sa bibliothèque perso ne va regarder du coté des normes. Par contre une entreprise qui fait des logiciel de compta va forcément appliquer les normes en vigueur (sinon, elle ne vendra pas beaucoup). En général quand on développe un gros soft sensé tourner sous Vista ou Seven, on va faire en sorte que le logiciel ne plante pas si on essaie d'écrire un fichier dans program files.
ça me faire rire quand je lis qu'un développeur n'est pas soumis aux normes !

Je développe quotidiennement des "petits softs dans mon coin", je fais "en sorte que le logiciel ne plante pas..." et sans y être SOUMIS, je me préocupe des normes et standards en vigueur (afin d'être compatible, évolutif, maintenable, ...), ... pourtant j'ai toujours des bugs...

Bref quand on se permet de faire des comparaison sur le beau métier de développeurs, il ne faut pas se contenter de se servir des vieux clichés. Il faut approfondir le sujet un minimum.

- "le beau métier de développeur", faut voir. Ca nécessite une discussion à part entière...
- La comparaison entre "jardinier" et "développeur" ne me semble pas être un vieux cliché
- "Il faut approfondir le sujet un minimum" : entierement d'accord. Nous sommes tous ici pour APPROFFONDIR et cette discussion est une occasion pour essayer de définir ce qu'est le métier de développeur logiciel. De quel métier se rapproche-t-il le plus (par ses méthodes, ses outils, ses contraintes, ...) ? Les comparaisons sont toujours un point de départ interessant pour définir une chose inconnue (ou mal connue) et non RECONNUE. N'ayons pas peur des comparaisons...

Ce qui m'ennerve le plus, c'est que l'auteur est développeur. Alors qu'il se fasse des idées sur le métier d'ingénieur ne me gène pas mais qu'il ne connaisse pas du tout ce qu'implique son propre métier, ça me mets hors de moi !

Il n'y a pas sujet à s'enerver mais plutot à réflexion. Un pavet dans la mare
(comme celui-ci) est toujours un bon moyen pour éclabousser et faire réagir les gens.

Les herbes poussent peut être dans un jardin, mais je n'en voit vraiment pas l'équivalent pour ce qui est du développement.

L'équivalent des mauvaises herbes dans un jardin serait pour moi des contraintes que pourrait subir un logiciel dans le temps et qui n'étaient pas prévues au départ (ou sous-estimées) : montée en charge des utilisateurs, sous-dimensionnement des capacités de stockage, ...

D'ailleurs, l'ingénieur et le jardinier ne font ils pas la même chose???
Pour moi tout ça revient au même concept qu'est la <<création>>. Qu'on soit ingénieur, jardinier ou je ne sais pas trop quoi, l'activité créatrice revêt les mêmes caractères, procédés, ...
Sur un tout autre plan, que d'étre comparé à un jardinier soit offusquant montre bien le mépris que nous avons de l'autre! "Il n'y a que de sottes gens" dit-on.
A+

Je suis d'accord. En tant que développeur, je me considère comme un "créateur", un batisseur. Par contre je pense qu'aujourd'hui, les "procédés" de créations sont loin d'être aussi efficaces que dans le batiment et que les résulats (taux de réussite, satisfaction client, ...) obtenus reste bien insuffisant

C'est complètement à coté de la plaque, comme analyse. Le problème de l'ingénierie logicielle est justement ce manque chronique de considération. Quiconque a utilisé Word pendant 5 minutes pense être en mesure de m'apprendre mon métier, résultat les décideurs informatiques ne nous prennent pas pour des jardiniers mais plutôt pour les nouveaux ouvriers spécialisés du XXIe siècle !

Quand j'entends parler de choses comme MDA ou des "usines à logiciel", je me marre !

"Le problème de l'ingénierie logicielle", c'est son efficacité !!! Les résultats attendus ne sont jamais là (ou rarement, ou partiellement, ...).
Le développeur sera considéré le jour où il aura fait comprendre à son patron (et son client) qu'il a + de pouvoir (de responsabilité) qu'un maçon dans la construction de son oeuvre, qu'une ligne de code bien écrite peut éviter 6 mois de tests ou éviter de mettre 10000 utilisateurs en rade et que pour écrire un ligne de code correctement il faut être formé, expérimenté et avoir de le temps de la réflexion.

C'est de la cuisine, c'est vrai. Mais c'est résoudre les vrais problèmes qui se posent dans la vraie vie, pas poser de belles équations pour résoudre les problèmes tels qu'ils devraient se produire.

Le développeur est finalement plus proche du cuisinier que du jardinier

La description de ses problèmatique montre clairement qu'il ne bosse pas dans l'aviation. La remarque est donc inutile.

Et accessoirement, si la comparaison qualitative est peut être à l'avanatge de l'aviation, celles sur la réactivité et les couts ne donne peut être pas le même résultat.

Mais à quel prix ? La qualité n'étant pas là, c'est un soft qu'il faudra livrer à nouveau dans 1 semaine, 1 mois, ...

Il a surement pleins de raison pour l'avoir construite là et forcement je ne suis pas en mesure de deviner lesquelles mais si on se base juste sur l'aspect géographique, ce n'est pas vraiment le meilleurs endroit.
Je suis bien d'accord pour dire que le japon n'est pas bien large et qu'il est secoué un peu de partout mais fukushima n'est pas vraiment dans la partie la plus large.
En me basant uniquement sur l'aspect géograpique, je l'aurais construite sur la plaine à la frontière de district de chubu et du district de Kanto.

Mais bon ce n'est pas le sujet de la discussion

Merci l'expert !!!

[M.Dolly]

Ici je donne un avis semi-objectif, entant qu'étudiant en étude d'ingénieur du numérique.
Je suis complètement d'accord avec cette personne, combien de fois j'ai entendu des développeurs prétendre tout connaître de l'informatique ou combien de fois j'ai vu des personnes déclarant qu'elles travaillent dans l'informatique sans être diplômés. C'est absurde l'informatique est une science et permet de dompter un outil très puissant. J'ai l'impression que ces personnes n'ont qu'une vision restreinte de l'informatique, que l'informatique c'est développer pour l'entreprise.

Je suis conscient que c'est dur à entendre mais sans avoir étudié on ne peut avoir un niveau acceptable en informatique, rien que pour pouvoir développer en équipe. Alors vous allez me dire : Mark Zuckerberg, Bill Gates; d'accord mais on a pas besoin d'avoir fait d'étude pour être dictateur et non plus pour diriger une entreprise (je parle de Bill Gates).

[el_slapper]

D'accord avec quasiment tout, mais j'aimerais détailler deux points :

(.../...)
Le développeur est finalement plus proche du cuisinier que du jardinier

Pas forcément. Il y en a, mais ça n'est pas obligé de s'arrêter là. D'ailleurs, entre la cuisine que je fais pour ma famille(sous le regard inquisiteur de mon épouse), celle que je fais pour moi tout seul(quand elle n'est pas là), celle d'un grand restaurant ou celle d'une usine agro-alimentaire, il y a aussi plein de différences. Les préjugés ne frappent pas que l'informatique...(et je viens de m'en redre coupable)

Mais à quel prix ? La qualité n'étant pas là, c'est un soft qu'il faudra livrer à nouveau dans 1 semaine, 1 mois, ...
(.../...)

Pas forcément. Il y a un risque supérieur, certes, mais en info de gestion, en programmes faits pour et par un seul client, le coup du bug n'est pas forcément rédhibitoire. ça dépend du bug. Et la qualité totale et prouvée peut s'avérer impraticable, voire contre-productive, par exemple quand on programme du réglementaire et que le reglementateur n'a pas laissé le temps de tout tester avant de livrer. Mieux vaut alors être en règle, quitte à essuyer quelques plâtres, plutôt que de risquer gros en étant hors-la-loi.

Attention, je ne parle pas du code. A mon sens, le code soit TOUJOURS être propre et maintenable, même pour du jetable.

Je parle de la profondeur de la validation et des tests. Je pense qu'une approche mathématique de démonstration de la perfection d'un code, bien que possible, ne permettra pas de rendre un produit fini, dans des délais acceptables et dans des couts acceptables. Sauf domaine ou c'est exigé, i.e. l'aérospatial.

Parcequ'un programme marketing, qui doit faire gagner 500 clients, à 800 €uros le client, si il coute 40 000 Euros, il devient difficille à rentabiliser. ça fait à peine une cinquantaine de jours, dans une grande entreprise... Et si il y a un bug véniel(qui fait rater un prospect sur mille), le cout de detection du bug(je ne parle même pas de la correction) est supérieur au cout final du bug.

[OverDarkDev]

Vos opinions sont très intéressantes.

Pour ma part, je trouve que les ingénieurs ne sont pas chanceux et pas très performant versus un jardinier.

Pour présentement être Technicien en génie mécanique et travaillant dans un bureau d'ingénierie, je vous assure qu'un développeur s'éguise beaucoup plus rapidement qu'un ingénieur car c'est très facile de tester 10000 fois plus vite qu'un ingénieur qui reste toujours dans la nébuleuse du doute. Un logiciel est simple à livrer et avoir confiance, il fonctionne, ou pas... blanc ou noir. Si un développeur est un excellent utilisateur et administrateur, il saura précisément ce que chacun a besoin pour trouver son compte. Un ingénieur est payé par les crédits de R&D donc n'a pas besoin d'être rentable... Une chance parce que c'est pas croyable comment ça fonctionne jamais et que les coûts s'accroissent constamment. Et à chaque échecs, il faut faire les changements (un dessinateur car l'ingénieur est beaucoup trop hot pour travailler) et attendre 1 mois que les pièces lui reviennent pour faire son test. Son salaire est régis par l'ordre et la valeur du marché et non sur sa rentabilité et sa rareté.

Je vais tenter de comparer les 2 domaines.

Ing: Faire un estimé soufflable et ce n'est pas grave car son salaire est payé.
Dev: Faire un estimé alléchante sinon l'employeur n'y croit pas et nous n'aurons pas le droit à 2 chances si ce n'est pas bon.

Ing: Faire des croquis (Faire faire est plus juste)
Dev: Faire un diagramme vulgarisé pour vendre l'idée

Ing: Faire un proto, produire, tester, recommencer, couter cher, reproduire, tester, recommencer, couter cher..
Dev: Lacher l'application quand ça fonctionne

Ing: Suivit des normes universelles obligatoire
Dev: Suivit des normes universelles optionnelles (va s'améliorer avec le temps)

Ing: Le gratte-ciel est fait et pour un autre, on recommence
Dev: Si on abstrait personnellement nos codes, 100% réutilisable

Ing: Doit pas connaitre grand chose pour être reconnu (juste une bonne bibliothèque de livre est vendeur)
Dev: Selon les offres d'emplois, il faut a peu près connaitre 15 fois plus de théorie, méthodes, applications. En plus d'être capable de porter plusieurs chapeaux.

Ing: Un ing n'est pas obligé d'évoluer et une bolt risque de rester un bolt dans les 25 prochaines années.
Dev: Les méthodes changent, les languages changes, les ordis changent, les framework changent et une adaptation rapide et efficace est nécessaire.

Tout ça pour dire que les développeurs ont déja la vie dure VS les ingénieures qui se croient les plus instruits quand c'est complètement faux. (Je parle bien sûr d'un vrai développeur passionné et non un petit wanna be).

Les développeurs sont la seule porte de sortie aux grosses firmes qui offre des applications buggés et jamais adapté mais avec la possibilité de l'adapter pour la modique somme de 150$/h. Je parle pour ma part mais mes applications sont évolutives, bien documentés, bug jamais, adapté précisément au contexte de mon entreprise, mes sub et fonction et classe sont tous réutilisable et j'ai un véritable arsenal pour l'interconnectivité de tous les logiciels chez nous ainsi que les BDD. Je ne suis ABSOLUMENT pas impressionné par les "grands penseur" que je tolère seulement parce que leurs salaires est créditable. J'espère très honnêtement que les ingénieurs du future soient plus performant et plus orienté vers le concret.

Une dernière chose, il est important pour un développeur de savoir quand il faut passer 100H a la planification d'une application sous C#.Net avec SQL server ou 20H pour finir un projet en optant pour Access et VBA

Merci

[shenron666]

il y a un truc que tu ne sembles pas avoir compris :
il existe des ingénieurs en développement

quoi qu'il en soit, en prenant ton post au second degré, j'ai bien ri

[OverDarkDev]

Bon point
Mais je crois que cette rubrique compare les "grands penseurs" avec les "exécutants". C'est très sarcastique mes termes parce que par définition, un "grand penseur" est juste quelqu'un qui n'agit pas mais quelqu'un qui agit qui ne réfléchit pas ne peut pas être rentable alors +1 pour les dév (non ING)