mais c'est pas mal d'être comparé à un jardinier, ils sont innovateurs, patients dans leur travail (
aime bien jardiner mais n'a jamais assez de patience pour voir grandir des plantes)
Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter
Cool quand j'irais aborder une fille je lui dirais que je suis jardiné, ça fait moins geek
Il faut le prendre avec humour je pense.
ça ressemble plus à un mea culpa, qu'à une étude.
L'ingénieur de la construction qui prévoit tout, le planning, la qualité, etc... c'est plutôt beaucoup de retard, de nombreuses erreurs de conception et autres. De mon entourage, je ne connais aucun bâtiment, qui n'est eu des retards, des problèmes de conception, voir de réalisation ou de finition.
Pour défendre un peu plus les développeurs, il y a beaucoup de développeurs, qui ne viennent pas du tout de l'informatique (électronique, physicien...) et qui vont se prétendre développeur, sans savoir réellement ce que signifie ce poste.
Ensuite pour la partie qualité, l'informatique reste une activité jeune, 40-50 ans d'existence, la construction... euh, plusieurs millénaire... alors oui, elle est plus réglementée, plus encadrée par son historique et nous avons une meilleure connaissance des conséquences d'anomalies de conception. Il est plus simple de faire des règles.
Dans l'idée, je préfère être comparé à un jardinier qui fait pousser de la vie verte à un constructeur qui l'écrase pour faire pousser du béton gris
Il oublie également que dans le bâtiment, avant de passer a la phase BTP où on est capable de prédire relativement bien les couts et les délais (et encore, comme ca a déjà été dit), il y a d'abord l'élaboration des plans, ca ne se fait pas en claquant des doigts, il y a un concept d'origine, qui va changer énormément avant d'arriver aux plans finaux.
Et c'est cette partie le boulot des ingénieurs, c'est pas la construction.
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.
La partie dont se chargent les ingénieurs c'est élaborer les plans (création d'un algo), construire des maquettes (première version de l'implémentation) et des modèles informatiques pour tester la fiabilité des plans (test unitaires).
Et a coup sur, leur premier modèle tient pas la route, du coup faut repartir en arrière et amener des correction (débogage).
Pour parvenir a une architecture plus robuste ils utilisent des techniques connues et reconnues pour résoudre les problèmes courants (tiens c'est pas la définition des design pattern ca ?)
On pourrait continuer longtemps comme ca.
Au final, je trouve que la comparaison avec le jardinage n'est pas si fausse, mais celle avec les ingénieurs l'est complètement. Il n'a pas comparé le boulot des ingénieurs, mais celui de la mise en œuvre.
Plop
Je vais dire un truc con, mais depuis quand un développeur est-il un ingénieur?
Personnellement je suis développeur débutant, et je ne suis pas ingénieur.
Ca m'a fait sourire le coup du jardinier, ca m'a rappeler une chanson :
"Savez vous plantez windaube ......"
Sinon pour avoir bosser pour un cabinet d'architecte je confirme que dans le batiment tout n'est pas aussi carré que le présente l'article, rien que par le fait d'avoir des sous-traitant l'empêche de l'être
++
Moi j'ai juste une Interrogation...
Les informaticiens qui ont le poste de "Software Architect" ou "Software Engineer" ne sont ils pas des Ingenieurs ?? au point de vue Informatique tout au moins!
Mais bien sur qu'un développeur n'est pas nécessairement un ingénieur !
il est possible d'être ingénieur en génie de la production, comme génie en production automatisé, en technologie de l'informationEnvoyé par ctxnop
après est-ce que ingénieur en technologie de l'information, ingénieur en génie logiciel sont réellement des ingénieurs?
il y a un débat là-dessus au québec étant donné que le titre d'ingénieur est protogé.....
exit, les programmeurs qui après deux ans devient par magie des ingénieurs php comme en france
Je vois pas trop le rapport entre ce que tu cites et ce que tu dis
Sinon, comme il a été dit ici plusieurs fois, tous les développeurs ne sont pas ingénieurs. Mais il existe bel et bien des développeurs qui sont ingénieurs, formés et embauchés en tant que tel et qui font un boulot comparable à n'importe quel autre type d'ingénieur (toute proportion gardée, les métiers étant très différents, il y a forcément de grandes différences entre chaque type d'ingénieurs).
Il est clair qu'il faut définir la notion d'ingénieur. Au départ, le titre d'ingénieur est un titre reconnu par l'état et attribué à la suite d'un concours ou d'un diplôme certifié (à l'origine pour les métiers de la construction j'imagine). Le problème c'est que le titre d'ingénieur a été galvaudé avec le temps et à ce titre beaucoup de développeurs ne sont pas ingénieurs (ayant fait la fac par exemple).
Ensuite, dans un questionnaire ou un formulaire officiel, il n'y a pas de métier "développeur" dans la liste : c'est ingénieur ou cadre au pire le mot générique qui se rapporte le plus.
Enfin il y a le "ressenti". Effectivement, le développeur à qui on file une spec (ou un post-it) et à qui on dit "code moi quelque chose" ne doit pas se sentir particulièrement ingénieur. Pour moi l'article fait plutôt référence aux développeurs qui ont un certain poids dans les choix techniques et conceptuels (développeurs libres, architectes).
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.
Tout à fait d'accord.
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 ..."
Ce monsieur n'a pas du regarder de très prés les grands travaux, il vrai que le tunnel sous la manche a été livré dans les délais en tenant les couts, ou bien alors le nouveau sarcophage pour Tchernobyl, c'est sur il sont dans les délais et dans les couts (Contrat 430 Million € cout estimé 1.5 Milliard €, livraison prévu pour 2012, estimation pas avant 2015),
mais à part c'est deux trois petits détails il est clair que les "INGENIEURS" sont beaucoup plus performants que les développeurs
Le tout est résumé dans le nouveau proverbe :
« à force de coder, on devient opérateur de saisie»
Salut
Nous inventons et cherchons perpétuellement pendant qu'ils appliques à tout moment. Quel chercheur peut prévoir ses délai et résultat?
L'analogie avec la construction est intéressante. Mais il faut bien préciser le contexte. La construction n'est pas une activité aussi jeune que le développement. Au moyen-âge, les essais/erreurs, ratage en tout genre, échec était fréquent. Imppossible de prévoir les délais, ni même le résultats.
Je ne vais certainement pas me faire des amis parmi les intéressés, mais en France, le titre d'ingénieur en informatique est un vieux reliquat de l'ère industrielle. En effet dans les années 60, on a naturellement abordé ce nouveau domaine du logiciel en y transposant des concepts qu'on connaissait : le génie (civil, militaire, mécanique, électrique, agronome... donc logiciel), l'ingénieur et les méthodes de travail associées.
Cf cette présentation de Laurent Bossavit très révélatrice sur l'histoire de notre métier : [ame="http://www.youtube.com/watch?v=72bE7VJ_5Ig"]YouTube - Quarante ans de crise, dix ans d'agilité avec Laurent Bossavit[/ame]
Pourtant les schémas des disciplines traditionnelles de l'ingénierie sont loin de s'appliquer correctement au monde du logiciel. Parmi de nombreuses dissimilitudes, on ne retrouve notamment pas en développement logiciel la même opposition expert qui conçoit/architecture/planifie VS technicien ou ouvrier peu qualifié qui exécute.
En effet le code n'est pas du ciment, un câble électrique ou même une pièce mécanique. Le code est ainsi fait que tout travailleur manipulant ce matériau de base, tout développeur donc, est amené à faire continuellement de la conception en même temps qu'il programme, d'une part car le besoin utilisateur est changeant et d'autre part parce qu'il est impossible de tout prévoir à la variable près avant de développer. Le Big Design Up Front et les plans au cordeau supposés parfaits dès le début marchent mal en développement logiciel, on s'en est rendu compte avec la grosse proportion d'échec des projets logiciels depuis que leur taux de réussite est mesuré.
Par ailleurs, le code est une matière complexe, abstraite, fragile, assez imprégnée du style et de la technique de la personne qui l'a créée et difficile à pénétrer et à maintenir après coup ; le travail du développeur devrait donc inclure la responsabilité de produire un code explicite, maintenable et évolutif, ce qui n'est pas trivial.
Le fait que tout développeur soit à mon avis confronté à des problèmes complexes de conception et d'implémentation (donc des domaines de responsabilité plus ou moins apparentés à de l'ingénierie si on emploie un vocabulaire historique) ne signifie bien sûr pas que tous les développeurs se valent et n'exclut pas des niveaux d'expertise différents en développement logiciel : débutant, confirmé, expert, gourou... ; des spécialisations ; des certifications... Mais ce n'est absolument pas la même division du travail que dans les disciplines d'ingénierie traditionnelles issues de la révolution industrielle.
Pour autant, il est amusant de noter qu'aujourd'hui encore, ce concept d'ingénieur est paré d'un certain prestige dont les acteurs du secteur ont du mal à faire abstraction. Certaines entreprises (SSII, éditeurs de logiciels) utilisent le mot "ingénieur" dans leurs titres de postes même si les gens qui les occupent n'ont pas ce diplôme (c'est mon cas, j'ai un bac +4 et sur mon contrat de travail le nom du poste est "ingénieur"). Peut-être parce que cela représente une meilleure vitrine pour la société ? Peut-être parce que leurs clients oeuvrant dans des secteurs traditionnels sont sensibles à la distinction ? En tout cas pour moi, rien ne permet d'affirmer que le potentiel d'un développeur bac +2 avec de l'expérience est fondamentalement plus limité que celui d'un diplômé d'école d'ingénieurs informatique. Et j'en vois des exemples vivants tous les jours.
A mon avis la métaphore du jardinier, même imparfaite, est donc bien plus cohérente que celle de l'ingénieur, et l'idée de vouloir à tout prix distinguer les ingénieurs en développement comme une race à part aussi incongrue que celle de promouvoir une caste d'ingénieurs jardiniers.
Le titre est provocateur, mais on comprend en lisant que le jardinier a un boulot bien plus difficile que l' "ingénieur" de base. Les lecteurs de ce forum seront surement d'accord.
C'est d'autant plus provocateur chez nous, où le développeur est une sous m.... au niveau de la hierarchie du projet.
Développer c'est facile, le developpeur est mauvais, on va lui coller un AMOA parce qu'il ne comprend pas ce qu'il code et le contraindre a des design pattern vu qu'il ne sait pas non plus comment il code...
Bref, j'en étais où déjà.. ahh oui mon web.config et mon service qui ne se lance pas
Je trouve l'article un poil un peu dur avec les jardiniers:
Selon D. Knuth, l'informatique est un art comme il l'a si bien écrit dans son "The Art of computer programming". D'autres considèrent que c'est une science à part entière comme les mathématiques appliquées, ...
Maintenant en pratique, le développement logiciel est loin d'être industrialisé mais le chemin parcouru depuis les années 80 est considérable ...
Répondre avec citation
Partager