L'artisanat est-il payant?
Doublons possibles:
Prototypage vs code propre aux premiers stades
Franchement, préférez-vous le codage Cowboy?
Après avoir travaillé dans plusieurs entreprises, je commence à réaliser que mon engagement à écrire des logiciels de haute qualité et bien testés ne mène pas nécessairement à l'avancement professionnel, en particulier lorsque les gestionnaires ayant des antécédents non techniques ne voient pas les avantages du code maintenable, et préférez les développeurs qui ont un semblant de productivité élevée, tout en accumulant des montagnes de dettes techniques.
Cela dit, j'ai tendance à m'en tenir à un code bien écrit parce que je trouve intrinsèquement gratifiant - ce sentiment que vous ressentez lorsque vous savez que vous avez bien fait votre travail, même si vous savez que vous ne serez pas crédité pour cela.
En partie, je peux combler l'écart de productivité en adoptant différentes technologies et approches tout en écrivant du code propre - les solutions incluent les langages dynamiques, la programmation polyglotte et la convention sur la configuration.
Mais mon dilemme demeure - l'artisanat est-il payant?
D'après mon expérience, la réponse est malheureusement non. J'ai perdu de nombreux emplois en raison de mon désir de pousser une culture de l'artisanat sur les hacks bâclés, les modèles de conception sur le code procédural écrit comme orienté objet et l'adoption de nouvelles technologies plutôt que de rester avec une technologie héritée obsolète. Notez que je n'ai pas regret ces choix, mais la réalité est que très peu de nos frères développeurs connaissent ou se soucient de l'artisanat; J'ose dire que nous sommes beaucoup plus nombreux à nous soucier moins de la "bonne" façon d'écrire des logiciels, ou ignorons même complètement qu'il existe de meilleures façons que la façon dont ils l'ont fait pendant des années. Bien sûr, j'essaie d'écrire mon propre code en pensant à l'artisanat, mais c'est en grande partie un effort futile, et souvent lorsque vous avez du code qui ne suit aucun artisanat, essayer d'ajouter même un peu est douloureux. Même les emplois que j'ai gardés, j'ai été relégué à des corrections de bugs mineurs au lieu de travailler sur de nouvelles choses (parce que si j'étais affecté à un nouveau développement, j'essaierais de présenter mes "idées radicales", c'est-à-dire l'artisanat), au point où je finir par en avoir marre/s'ennuyer et chercher une autre entreprise dans l'espoir d'en trouver une qui comprend l'artisanat.
Je regarde et j'envie les gens qui sont entrés dans des environnements où ils ne sont pas la seule personne qui connaît l'artisanat du logiciel, ou les SOLID, ou ORMS/IoC/SOC/etc, car ils n'ont pas à se battre pour essayer de dire aux gens que non, c'est mauvais de regrouper toutes vos fonctions dans une classe gigantesque qui pourrait aussi bien être un module VB6; c'est mauvais d'avoir un fichier de code qui a une méthode qui dure mille lignes; il est mauvais de mettre toute votre logique dans le gestionnaire d'événements d'un bouton. Ils n'ont pas à risquer d'être renvoyés parce que vous continuez d'essayer d'éduquer votre équipe sur de nouvelles et meilleures façons de faire des choses; des moyens qui amélioreront la longévité et la maintenabilité de la base de code, pour ne rencontrer que des regards confus ou des renvois parce que vous êtes la seulement personne qui sait même pourquoi c'est une bonne chose, ou vous êtes la seule personne qui s'abonne à des blogs/podcasts techniques pour s'améliorer.
En six ans de travail en tant que développeur de logiciels, j'ai eu exactement un emploi sur environ six entreprises qui se préoccupaient réellement de l'artisanat. Tous les autres endroits ne connaissaient pas ou ne comprenaient même pas les avantages - essayer d'expliquer les choses aux autres membres de l'équipe a eu cet étrange "Wha ...?" genre de regard, comme s'ils ne comprenaient rien de ce que je disais. Les entreprises auraient préféré garder les développeurs paresseux qui n'ont rien amélioré et ont même refusé d'être au courant de quelque chose de nouveau, plutôt que d'encourager des techniques de développement appropriées qui faciliteraient la maintenance à long terme, au lieu de cela, elles sont toutes trop disposées à sacrifier à long terme. terme à court terme. A chaque fois.
Pour résumer: l'artisanat ne sera rentable que si toute l'équipe l'adopte. Si une personne embrasse l'artisanat et que les autres ne savent pas ce que cela implique, cela ne paiera pas du tout et vous blessera probablement.
ADDENDUM
Juste pour prouver mon point de vue, j'ai écrit ceci en juin 2011. J'ai été licencié en tant que développeur dans l'entreprise dans laquelle je travaillais en juillet '12 pour exactement les raisons indiquées ici: Au cours de cette période de 13 mois, j'ai essayé de nous pousser vers l'utilisation d'un semblant de savoir-faire au lieu de pirater des conneries qui n'étaient pas maintenables (pour donner un exemple, nous essayions de vendre notre logiciel CRM interne à d'autres entreprises, alors qu'il pouvait à peine supporter les quelque 70 utilisateurs que nous avions en interne et devaient être redémarrés plusieurs fois par jour en raison d'un crash). Un développeur "senior" a contrecarré mes efforts à chaque étape du processus et le CTO non technique l'a toujours soutenu malgré qu'il me dise en personne que la bonne qualité était un objectif, et cela a abouti à mon entrée dans la salle de conférence avec le Le CTO et les RH doivent être informés que mes compétences en développement n'étaient "pas [mon] point fort" et l'entreprise voulait aller dans une direction différente de celle que j'essayais de pousser (c'est-à-dire un environnement avec des choses telles que les révisions de code et les conventions de code et le savoir-faire), et que mes services n'étaient plus nécessaires.
Il m'a fallu près de 5 mois pour trouver un autre emploi, et ce travail ne fait aucun développement du tout au-delà de certains SQL; Je travaille avec des applications propriétaires toute la journée, et ma volonté et mon désir de recommencer le développement sont pratiquement révolus parce que je suis fatigué de scénarios comme celui-ci tout le temps. J'ai récemment eu deux entretiens d'embauche où je n'ai pas été retenu pour le poste par la suite (l'ancienne excuse "Nous sommes allés avec un autre candidat") parce que, je pense, les entreprises ont estimé que je ne serais pas d'accord avec "leur vision du logiciel "en grande partie, en partie, à mon enthousiasme à vouloir suivre de bons principes de conception et adhérer à l'artisanat du logiciel.
Donc, pour réitérer ce que j'ai déclaré il y a plus de deux ans: dans la plupart des cas, du moins d'après mon expérience, l'artisanat vous fera virer ou être disqualifié si personne d'autre s'en fout, et la plupart des entreprises s'en foutent il; la plupart des entreprises ne savent même pas ce que c'est. Chaque fois que j'ai mentionné un bon design ou des choses comme les ORM ou les principes SOLID ou quelque chose comme ça, j'ai l'habitude de voir des regards vides et ce sentiment de naufrage dans lequel je viens de me tirer dessus) le pied parce que le gars qui m'interroge n'a aucune idée de ce que sont ces choses. Malheureusement, ce sentiment de naufrage s'est avéré correct à chaque fois.
Voici quelques chiffres à considérer :
- En 2000, des recherches ont révélé que jusqu'à 90% du coût total des systèmes logiciels étaient consacrés à la maintenance et à l'évolution. Dans l'ensemble, la recherche a révélé qu'au moins 50% du coût d'un système logiciel est en maintenance.
- Aux États-Unis seulement, les coûts de maintenance annuels approchent les 70 milliards de dollars.
En passant du temps à suivre les bons principes d'ingénierie depuis le début du projet jusqu'à la fin de vie du système, ces chiffres peuvent être réduits, ce qui est bon pour les résultats de votre organisation. Il existe de nombreuses facettes ici, allant de la production d'une documentation technique efficace pour les futurs développeurs à l'envoi de code et de tests bien écrits. Vous pourriez avoir passé un peu de temps supplémentaire à l'améliorer maintenant, mais cela portera ses fruits lors des phases de maintenance.
L'artisanat est-il payant? C'est le cas, mais vous devez passer au niveau supérieur.
Lancez votre propre entreprise et offrez un produit qui bat la concurrence. Ensuite, vous obtiendrez tous les résultats de votre bon travail avec vos propres clients.
Dans la plupart des emplois occupés, les gens recherchent la reconnaissance et ne la trouvent jamais. Dans de nombreux cas, lorsque cette reconnaissance arrive, elle le fait, mais beaucoup plus tard, lorsque la personne est déjà passée à l'endroit suivant. Ensuite, vous vous souviendrez avec de bonnes paroles, mais en post mortem.
D'après mon expérience, lorsque la plupart des programmeurs parlent de "savoir-faire", ils signifient généralement du code sur-conçu souvent pré-conçu pour gérer les fonctionnalités futures. Le concept de "juste assez bon" est souvent confondu avec une qualité médiocre et considéré comme l'opposé de "l'artisanat".
Au contraire, les programmes les mieux conçus sont simples et directs, contiennent à peine assez de code pour faire ce qu'ils sont censés faire et sont plus faciles et plus rapides à écrire et à tester que les programmes bâclés. Ce sont les astuces intelligentes et la planification d'un avenir qui pourraient ne jamais arriver qui prennent le temps de l'artisan et le rendent plus lent que le programmeur bâclé.
Voici un choix que mon équipe a eu une fois. La société pour laquelle je travaillais a tourné plus de 10 millions/an. La division que j'ai rejointe perdait 500K/mois, l'entreprise était financée par une caution sur la maison des patrons.
Choix 1. Meilleure pratique. Le tout ... aurait mis le propriétaire en faillite.
Choix 2. Grand salon professionnel en 10 semaines. 8 développeurs, mode guerre. Pas de design, pas de documents, pas de tests. Le propriétaire a vendu 3 ans plus tard et a mis 50 millions sur son compte bancaire personnel, la division tournant plus de 200 millions d'euros. (quelle promenade excitante c'était)
Le code était, selon tous les standards logiciels et le disait franchement, merde, non documenté, non maintenable et illisible. Il était cependant (étonnamment même pour moi), fiable. Selon les normes business, le code était irréprochable.
Le point culminant de ma carrière à ce jour, "écrire du code merdique qui a fait beaucoup d'argent, et je suis fier de ça, parce que j'ai fait exactement ce pour quoi j'étais payé."
(Je joue un peu l'avocat des démons ici):
.
Chaque partisan de BP que j'ai vu est a) un vendeur, ou b) un universitaire. Vous voyez rarement une vue comptable sur BP publiée et vous voyez rarement une analyse complète des coûts, y compris le coût en capital, le coût du temps, le coût d'opportunité, etc. pris en compte dans les avantages de BP.
L'artisanat est payant lorsque vous êtes en mode maintenance plutôt que d'essayer de sortir rapidement un nouveau produit.
. rappelez-vous votre nom sur une construction particulièrement hideuse quand et si jamais ils vous rencontrent lors d'un entretien d'embauche des années plus tard et vous le reprochent.
Je vais être d'accord avec certaines des réponses et légèrement en désaccord avec certaines. J'adore @ Thomas Owens lien vers les données numériques sur la maintenance. Cela fait vraiment ressortir le niveau de maintenance et le temps/argent que vous pouvez économiser avec un peu de savoir-faire.
Plusieurs personnes ont déclaré que le savoir-faire était payant plus tard, mais seulement plus tard. Cela rapporte définitivement plus tard. Soit vous finissez par maintenir vous-même un bon code et vous économisez du temps/de l'argent, soit vous transmettez ce code à quelqu'un d'autre qui envoie des pensées heureuses en forme de cœur flou à chaque fois qu'il voit votre code et qu'il est facile de le maintenir .
Certains ont dit que cela ne payait pas maintenant. Je suis fortement en désaccord avec cette affirmation. J'ai travaillé dans plusieurs environnements où le changement se produit rapidement. Dans certains cas (pour citer un film) "ça vous prend entre deux bouchées". Si vous disposez d'un code bien conçu, lisible et structuré dans un cadre solide, lorsque ces changements arrivent, ils sont beaucoup plus faciles à gérer. J'ai trouvé personnellement qu'avoir une bonne structure de base pour tout projet aide à atténuer les changements d'exigences soit parce que l'entreprise est indécise soit que les besoins du client évoluent rapidement.
Dans le même ordre d'idées, j'ai récemment été témoin d'une situation avec un collègue qui n'avait pas une bonne ossature à son projet et écrit régulièrement un code lamentablement impossible à maintenir. Lorsque les exigences ont changé pour lui, il a été contraint de reprendre une grande partie de son travail "selon la formule" et de recommencer au début.
Réponse courte -
Dans les grandes organisations - il y a de fortes chances que ce ne soit pas le cas.
Dans les petites organisations ou si vous allez en solo (offrant votre savoir-faire en tant que produit ou service) - il y a de fortes chances que ce soit le cas.
L'artisanat porte ses fruits, mais pas beaucoup plus tard.
Le problème est que la plupart des organisations liées à l'informatique sont jeunes et n'ont pas encore eu temps pour se rendre compte qu'indépendamment de la portée, le logiciel devrait durer longtemps, et il doit être bien construit pour pouvoir le faire si correctement sans dépenses hideuses lorsque des changements sont nécessaires.
Cela implique que vous devez trouver un emploi dans une organisation où cette réalisation a été effectuée et la façon de travailler adaptée en conséquence. Sinon, vos efforts ne seront pas appréciés, ce qui est très insatisfaisant.
Ressentez-vous une grande honte lorsqu'un bug est détecté dans votre logiciel?
Voulez-vous revenir à vos anciens projets pour corriger les bugs tout le temps plutôt que de travailler sur votre projet actuel?
Voulez-vous que les développeurs du futur réécrivent votre code plutôt que de corriger un bogue?
La plupart des managers voient avec le temps qui sont les bons développeurs. Ces développeurs ont tendance à obtenir le projet le plus visible et souvent les plus intéressants. L'avancement professionnel tend à être davantage axé sur le perfectionnement professionnel que sur le travail réellement effectué. Si vous souhaitez obtenir une certification professionnelle, allez dans des classes commerciales, recherchez des opportunités de vous impliquer dans des projets en dehors de votre portée normale. Lorsque vous faites votre travail, vous êtes récompensé par un chèque de paie. Lorsque vous êtes au-delà, vous commencez à voir des progrès.
Il ne s'agit pas de la technique d'être un artisan, mais de être un artisan. Léonard se demanderait-il si cela valait la peine de peindre à l'huile? Un menuisier expert se demanderait-il s'il avait vraiment besoin de poncer soigneusement chaque pièce d'un meuble qu'il fabrique?
Non, nous sommes des artisans et c'est ce que nous faisons. Faire les choses différemment serait contraire à notre nature et lorsque vous commencez à emprunter la voie de "l'effort minimal requis", vous perdez votre fierté de travailler et votre volonté d'amélioration continue.
Cela étant dit, il y a des choses pratiques que vous devez prendre en considération mais ne faites jamais rien que vous auriez honte de montrer à quelqu'un d'autre.
L'artisanat est-il payant ??
Oui, mais ça ne paie pas pour tout le monde également.
- Il est rentable pour le développeur principal ou le gestionnaire de développement qui assume la responsabilité ultime de la base de code.
- Cela rapporte au développeur qui doit apporter des modifications à sa bande étroite de la base de code.
- Il est rentable pour l'entreprise lorsque le développement doit apporter ou modifier ou supprimer des corrections de bogues.
- Cependant, cela pas est payant pour le développeur, le gestionnaire ou l'entreprise qui doit respecter un délai agressif et inflexible.
Deux commentaires:
- En tant que développeur, vous devriez fortement privilégier le chemin "artisanat" car il vous sera invariablement demandé de modifier et de prendre en charge votre code.
- Lors du choix de votre prochain emploi, essayez de déterminer si l'environnement de travail prend en charge le chemin "artisanat".
- Si ce n'est pas le cas, vous devriez être compensé pour les problèmes qui découleront invariablement du code piraté.
En tant qu'ingénieur logiciel travaillant sur l'expédition de produits, vous avez plusieurs contributions à l'entreprise:
Gagnez plus d'argent que vous ne leur en avez coûté cette année.
Gagnez plus d'argent que vous ne leur en coûte l'année prochaine.
L'écriture rapide de code est la façon dont vous atteignez le premier; l'écriture de code de manière durable est la façon dont vous atteignez la seconde. Vous et votre représentant commercial (gestionnaire ou autre représentant des intérêts commerciaux) devez collaborer pour hiérarchiser ce qui est fait.
D'après mon expérience, le code ne meurt jamais, et l'écriture de code modulaire et bien commenté porte ses fruits très rapidement.
Certaines entreprises vivent de la succion des clients dans des années de maintenance, il est donc dans leur intérêt de fournir des produits 1.0 rapides qui ne font pratiquement pas le minimum et prennent très longtemps à le maintenir.
De plus, il est plus facile pour ce type de suceurs de sang de justifier les coûts de maintenance lorsque les choses se brisent à la première interaction différente du script de démonstration que lorsque tout fonctionne bien.
C'est peut-être le genre d'entreprises dans lesquelles vous vous êtes retrouvé, donc la culture d'entreprise n'encourage pas vraiment l'artisanat.
Je vais supposer que le développeur est capable d'écrire du bon code et a donc le choix entre écrire du code maintenable et non.
Êtes-vous dans un délai serré?
Oui - faites-le. Vous ne voulez pas être celui qui retarde le lancement.
Si non: êtes-vous une personne égoïste ou égocentrique?
Non - écrivez un bon code, c'est bon pour tous ceux qui entrent en contact avec lui.
Si oui: êtes-vous dans une situation où la révision du code a lieu?
Oui - puis écrivez du code maintenable, sinon ce que vos pairs et votre patron voient de votre travail, c'est qu'il est de mauvaise qualité.
Non - c'est à vous de décider, mais plus vous arrivez rapidement à une solution, plus vous avez de temps pour faire d'autres choses.
Si non alors êtes-vous dans une situation où vous serez celui qui maintient le code que vous écrivez?
Oui - écrivez un mauvais code. Ensuite, vous avez la possibilité de le réparer et de ressembler à un héros. Les gens seront heureux parce que vous continuez de leur faciliter la vie au fil du temps. Si vous faites tout cela en même temps, ils pourraient vous oublier. Cela augmentera vos chances de bonus et de promotion.
Si non alors travaillerez-vous avec les mainteneurs, ou dans le même département??
Oui - il vaut probablement mieux écrire du bon code, car ils deviendront une source de louanges pour votre travail, ou au pire un silence.
Non - Écrivez votre code et continuez. Peu importe à quel point c'est grave, quelqu'un d'autre peut le réparer.
Ce sont les marchands qui sont mieux payés. La chose la plus importante est de faire le travail. L'utilisateur ne se soucie pas des détails techniques qui n'affectent pas son expérience utilisateur.
Lors de l'écriture de code, c'est parfois que artiste est meilleur que l'artisan. Craftsman fait juste son travail tel qu'il est décrit dans les livres tandis que les artistes s'assoient et inventent la solution au problème.
Notez également qu'en faisant les choses "comme il se doit", vous écrivez généralement du code qui nécessite des compétences techniques plus élevées pour être maintenu. Lorsque l'entreprise est basée sur la `` main-d'œuvre bon marché '' qui écrit du bon code par un bon programmeur (et donc cher), cela nécessite plus que des notions de base pour comprendre, ce n'est pas la solution optimale.