Si un employeur potentiel vous disait qu'il «externalisait la correction de bugs parce que les développeurs détestaient corriger les bugs», qu'en pensez-vous? Quelles pourraient être vos préoccupations?
Les développeurs détestent corriger les bugs? Je pense que c'est plus qu'ils détestent trouver un moyen fiable de reproduire le bogue, ce à quoi servent les testeurs. Si vous sous-traitez la correction de bogues, vous pouvez également externaliser toute l'équipe de développement. Personne ne comprend le code aussi bien que la personne qui l'a écrit lui-même .
Rob
1
Cela ressemble à une idée terrible.
Andres F.
1
@AndresF. +1. Cela créera un environnement où les développeurs jetteront juste de la merde au mur et espéreront que ça colle. N'est-ce pas leur problème si ce n'est pas le cas, non?
MrFox
Réponses:
25
Corriger nos propres bugs fait de nous un meilleur développeur . Et c'est un moment assez agréable pour moi. Surtout quand ils sont bien signalés.
S'ils n'aiment pas corriger les bugs, le problème est ailleurs.
Je soupçonne que le problème est de savoir comment les bogues sont perçus par la direction ou pire, par de mauvaises décisions de conception et / ou pas de tests (unitaires), ce qui rend la correction des bogues douloureuse.
L'externalisation de la correction de bugs ne fera qu'empirer les choses.
Les développeurs peuvent être tentés de réduire la qualité. On s'en fout? Certains gars offshore sont là pour nettoyer leur gâchis.
Jusqu'à ce que les gars offshore remplacent les gars onshore.
@Aditya: rien d'effrayant ici, c'est EXACTEMENT ce qui se passe chez mon dernier employeur. Les gars de l'offshore en ont eu assez pour corriger les bugs tout le temps et leur manager (amen à lui) a commencé à fournir une formation. À un moment donné, ils sont devenus assez bons pour commencer de simples rénovateurs, des nettoyages, etc. Pendant ce temps, au bureau principal, rien n'a changé. Je peux très facilement voir que l'année prochaine, les gars de l'offshore feront la plupart du travail et les gars du bureau principal ... enfin ... dommage qu'ils n'aient pas vu le train arriver ;-P
Newtopian
15
Partez , fuyez ... vite et ne regardez jamais en arrière ...
J'ai travaillé pour une telle entreprise, ils pensaient qu'ils étaient intelligents,
Hé, nous avons tous ces bugs, mais nos seniors se plaignent qu'ils passent trop de temps à corriger les bugs.
ouvrons un bureau offshore et laissons les autres s'en occuper.
pour un manager qui sonne comme un très bon plan et les développeurs ont finalement été libérés pour s'attaquer à la tâche la plus intéressante de créer la prochaine meilleure chose !!
ho ... mais attendez ...
après deux ans, ils sont passés d'une équipe de 5 développeurs dans leur bureau principal qui a tout géré à une équipe de 2 qui créent de nouvelles choses et une équipe de 30 qui trouvent et corrigent des bugs.
vous savez quoi ... l'équipe de correction de bugs a du mal, elle ne peut pas suivre.
cela rendait les "seniors" totalement inexplicables de leurs propres erreurs. Pire encore, parce que tout s'est passé si loin que la direction ne s'en est pas rendu compte non plus et que la qualité du code a chuté TRÈS vite à partir d'un niveau de qualité déjà abyssal.
Quand je suis parti, ils ont déjà ouvert deux bureaux supplémentaires pour les correcteurs de bogues et ils ne peuvent toujours pas suivre le seul développeur qui les a créés. ils pensent en fait que c'est parce que les nouveaux gars ne sont pas assez intelligents ...
Alors oui, à partir de maintenant, si une entreprise dit qu'elle a externalisé sa correction de bugs dans un bureau à l'étranger, faites-moi confiance ... je cours ... vite.
Il s'agit de la méthodologie de gestion Paper Bag .
Tenez-vous sur un chemin de fer, attendez l'arrivée d'un train, quand vous le voyez, mettez un sac en papier au-dessus de votre tête et ... POOF .. train disparu !!. La magie !
Demander à l'entreprise de payer quelqu'un d'autre pour nettoyer mon gâchis semble être une bonne idée, sauf lorsque je suis censé prendre son code «propre» et ajouter de nouvelles fonctionnalités. Et s'ils l'obtiennent tellement foiré qu'ils ne peuvent pas le réparer, vous déboguerez le débogage.
Il n'est pas souhaitable de ne pas être correctement rémunéré car ils doivent embaucher des développeurs supplémentaires.
Devoir passer un temps disproportionné à éduquer les autres développeurs quand vous auriez pu le réparer vous-même est contre-productif.
Une partie de moi pense que ceux qui créent des problèmes devraient être ceux qui les résolvent ou il n'y a aucune incitation à éviter de créer des bogues en premier lieu.
Les développeurs ne sont-ils pas intéressés à apprendre de leurs erreurs? Pouvez-vous corriger des bogues sans connaissance spécifique du domaine, et le partenaire d'externalisation a-t-il cette connaissance? La partie de fixation est la plus simple la plupart du temps, c'est la partie d'analyse qui prend le temps. De mon point de vue, c'est une décision stupide.
Si un employeur potentiel vous disait qu'il «externalisait la correction de bugs parce que les développeurs détestaient corriger les bugs», qu'en pensez-vous? Quelles pourraient être vos préoccupations?
Je courrais loin, loin, très loin. Un développeur est toujours, toujours, toujours responsable de corriger ses propres bugs. Manger sa nourriture pour chien est un principe de base d'une bonne ingénierie.
De plus, la correction des bogues est aussi importante, peut-être plus que le développement. Je veux dire, le développement est l'écriture de code, les tests et le débogage / correction.
Ce que j'obtiens de cette société, c'est qu'ils traitent la correction de bogues comme une tâche de deuxième classe. Cela en soi est assez dérangeant et je remets fortement en question leur qualité de travail (et ergo, leur environnement de travail.) Plus inquiétant, c'est qu'ils délèguent ce qui pour eux est un travail de seconde classe à des travailleurs offshore. C'est plus inquiétant. Il y a clairement une stratification sociale inscrite dans leur processus d'ingénierie.
Un défaut est toujours à l'origine d'un changement, et généralement le bogue est la responsabilité de celui qui a introduit le changement. Qui mieux que l'expéditeur pour comprendre la nature du bogue et sa résolution?
S'il est délégué à travers le monde, comment s'assurer que l'auteur original est disponible pour l'ingénieur délocalisé?
Sera-t-il même disponible, laissant l'ingénieur délocalisé qui n'a rien d'autre qu'un arriéré de bugs et de délais, mais aucun soutien de la Métropole ? Quel type de correction de bogue une personne pourrait-elle espérer effectuer? Qui corrige ses bugs? Et qu'est-ce qui empêche les développeurs de Metropole d'apprendre via la correction de bugs post-mortem?
Il y a des connards dans tous les domaines. Cela est particulièrement vrai dans les logiciels. Comme c'est inévitable, votre seule option est de travailler avec des connards qui en savent plus que vous ou qui font les choses correctement. Cette entreprise ne semble pas correspondre à cette description.
"De plus, la correction des bogues est aussi importante, peut-être plus que le développement." Je sais ce que vous voulez dire ici, mais j'irais jusqu'à dire: je ne peux pas comprendre une telle dichotomie. La correction de bogues est un aspect intrinsèque et fondamental du développement.
Dan Ray
1
@Dan - oui, votre déclaration est beaucoup plus correcte. Une telle dichotomie n'existe pas.
luis.espinal
4
S'attendent-ils vraiment à ce qu'un tas de développeurs juniors off-shore puissent réparer un tas de code de développeurs seniors? C'est comme demander à une infirmière de vérifier tous les neuroligistes et de les refaire là où il a fait des erreurs. MAUVAISE IDÉE!
Je serais préoccupé par la façon dont leurs employés connaissent réellement le code qu'ils développent.
Je me demande également la raison pour laquelle il y a suffisamment de bugs pour justifier les coûts supplémentaires que cela entraîne. Je m'inquiéterais également de l'avenir à long terme de l'entreprise, il existe de nombreux articles sur le Web qui prétendent que ces entreprises utilisent le même code pour plusieurs projets, même dans la même industrie.
La correction du code défectueux fait partie du processus d'écriture du code, il vous permet d'avoir une meilleure compréhension de ce que vous avez fait de mal il y a 6 mois, donc vous ne faites pas la même erreur, si un autre développeur corrige vos erreurs, comment éviter cela bug de se produire encore et encore?
Cela ressemble vaguement à mon employeur précédent, à l'exception du bit "employeur potentiel". Ils ont perdu les développeurs à cause de l'attrition et en ont perdu trop pour prendre en charge les produits existants tout en ajoutant de nouvelles fonctionnalités requises par les modifications des lois et des réglementations (60% des revenus du bureau proviennent d'un produit basé sur VB6, et MS a déclaré que les temps d'exécution du VB6 ne sera distribué dans aucun système d'exploitation futur, ce sera donc comme lorsque Vista est sorti - une course folle pour réparer les choses). Les pouvoirs en place veulent rendre l'entreprise publique bientôt, donc ils privent tout le monde de ressources pour rendre le bilan plus beau qu'il ne l'est - donc l'embauche à l'étranger est le seul moyen même de se rapprocher de rester sur le marché.
D'après mes expériences, ce que dit la citation est que votre employeur potentiel est bon marché.
+1 pour avoir le pire emploi possible. Il semble qu'ils n'aient pas utilisé suffisamment de ces revenus dans le projet.
Ramhound
sauf pour le bit "employeur potentiel" <LOL
Greg B
Je remarque l'expression «employeur précédent». Toutes nos félicitations.
David Thornley
@Ramhound, David, Greg, C'était un meilleur endroit quand j'ai commencé, j'ai quitté l'endroit fin décembre (peu après mon 5e anniversaire). Personne n'avait été embauché depuis mon embauche et au cours des 2 dernières années, 6 développeurs ont démissionné. Le dernier à partir était là depuis 11 ans.
Tangurena
3
Cela dépend de ce qu'ils entendent par "correction de bugs". Si cela corrige des bogues pendant le cycle de développement / test, alors c'est très étrange, c'est le travail des développeurs d'origine. Si, d'autre part, ils signifient qu'ils ont externalisé la maintenance d'un produit publié, ce n'est pas inhabituel et ce n'est pas quelque chose dont je m'inquiète.
Bon point, personne d'autre n'a envisagé cet angle.
Greg B
@Greg & Steve - Je ne pense pas que ce soit important pour être honnête. S'ils corrigent des bogues dans une version, par exemple, comment ces correctifs peuvent-ils être fusionnés dans la version de test si les développeurs n'écrivent pas eux-mêmes les correctifs.
Ramhound
Si les corrections de bogues sont archivées pour le contrôle de code source, elles peuvent facilement être corrigées par une autre équipe dans une autre branche. Ce n'est pas grave du tout.
Steve
Vous faites valoir un bon point, même si j'approuve vraiment ce scénario uniquement dans le cas où l'application est un système hérité qui n'est plus en cours de développement actif mais qui doit rester fonctionnel pour une raison quelconque. Disons une nouvelle génération qui est une réécriture complète de celle en question.
Newtopian
2
D'après mon expérience, le fait de faire appel à une équipe externe après le fait brûlera autant de temps que de corriger vos propres bugs - ils doivent être mis à jour et intégrés au processus de développement. Et puis gardé à jour en continu. La coordination est plus difficile que d'écrire du code.
Si je vais travailler sur une base de code, j'aimerais avoir l'assurance que tous ceux qui ont des privilèges de validation sont raisonnablement compétents. Cela inclut un certain nombre de personnes en Inde, par exemple, mais pas celles qui sont généralement délocalisées.
De plus, la plupart de mes bogues se trouvent dans des sections de code plus compliquées, et ce sont ceux que le programmeur offshore est le moins susceptible de comprendre avant d'appliquer une correction de bogue.
Cette politique existe en fait inconsciemment dans certaines entreprises. Je travaille pour un donneur d'ordre; mes collègues et moi-même sommes des programmeurs plus compétents que les gars sur place, ils nous demandent de leur apprendre à utiliser des outils, etc., mais l'autre côté est que nous décelerons les problèmes dans leur code plus rapidement qu'eux.
Généralement, les programmeurs du client sont physiquement situés dans le même bâtiment qu'au moins certains des utilisateurs, de sorte qu'ils sont plus susceptibles d'obtenir un contexte qui ne s'étend pas à travers les hémisphères. Nous trouvons que cela fonctionne bien, la partie manquante pour moi est qu'ils ne révisent pas notre code, donc lorsque le contrat se termine, ils peuvent avoir des surprises ou des questions, non pas à cause de pratiques de mauvaise qualité de notre part nécessairement, mais juste les problèmes habituels que vous avez lorsque reprendre le projet de quelqu'un d'autre.
En tout cas, je suis heureux que dans notre cas, ce ne soit pas une politique officielle, en tant que telle, je pense que cela éroderait les programmeurs sur site en étant un peu plus que des BA.
Réponses:
Corriger nos propres bugs fait de nous un meilleur développeur . Et c'est un moment assez agréable pour moi. Surtout quand ils sont bien signalés.
S'ils n'aiment pas corriger les bugs, le problème est ailleurs.
Je soupçonne que le problème est de savoir comment les bogues sont perçus par la direction ou pire, par de mauvaises décisions de conception et / ou pas de tests (unitaires), ce qui rend la correction des bogues douloureuse.
L'externalisation de la correction de bugs ne fera qu'empirer les choses.
Les développeurs peuvent être tentés de réduire la qualité. On s'en fout? Certains gars offshore sont là pour nettoyer leur gâchis.
Jusqu'à ce que les gars offshore remplacent les gars onshore.
la source
Partez , fuyez ... vite et ne regardez jamais en arrière ...
J'ai travaillé pour une telle entreprise, ils pensaient qu'ils étaient intelligents,
Hé, nous avons tous ces bugs, mais nos seniors se plaignent qu'ils passent trop de temps à corriger les bugs.
ouvrons un bureau offshore et laissons les autres s'en occuper.
pour un manager qui sonne comme un très bon plan et les développeurs ont finalement été libérés pour s'attaquer à la tâche la plus intéressante de créer la prochaine meilleure chose !!
ho ... mais attendez ...
après deux ans, ils sont passés d'une équipe de 5 développeurs dans leur bureau principal qui a tout géré à une équipe de 2 qui créent de nouvelles choses et une équipe de 30 qui trouvent et corrigent des bugs.
vous savez quoi ... l'équipe de correction de bugs a du mal, elle ne peut pas suivre.
cela rendait les "seniors" totalement inexplicables de leurs propres erreurs. Pire encore, parce que tout s'est passé si loin que la direction ne s'en est pas rendu compte non plus et que la qualité du code a chuté TRÈS vite à partir d'un niveau de qualité déjà abyssal.
Quand je suis parti, ils ont déjà ouvert deux bureaux supplémentaires pour les correcteurs de bogues et ils ne peuvent toujours pas suivre le seul développeur qui les a créés. ils pensent en fait que c'est parce que les nouveaux gars ne sont pas assez intelligents ...
Alors oui, à partir de maintenant, si une entreprise dit qu'elle a externalisé sa correction de bugs dans un bureau à l'étranger, faites-moi confiance ... je cours ... vite.
Il s'agit de la méthodologie de gestion Paper Bag .
Tenez-vous sur un chemin de fer, attendez l'arrivée d'un train, quand vous le voyez, mettez un sac en papier au-dessus de votre tête et ... POOF .. train disparu !!. La magie !
la source
Demander à l'entreprise de payer quelqu'un d'autre pour nettoyer mon gâchis semble être une bonne idée, sauf lorsque je suis censé prendre son code «propre» et ajouter de nouvelles fonctionnalités. Et s'ils l'obtiennent tellement foiré qu'ils ne peuvent pas le réparer, vous déboguerez le débogage.
Il n'est pas souhaitable de ne pas être correctement rémunéré car ils doivent embaucher des développeurs supplémentaires.
Devoir passer un temps disproportionné à éduquer les autres développeurs quand vous auriez pu le réparer vous-même est contre-productif.
Une partie de moi pense que ceux qui créent des problèmes devraient être ceux qui les résolvent ou il n'y a aucune incitation à éviter de créer des bogues en premier lieu.
la source
Les développeurs ne sont-ils pas intéressés à apprendre de leurs erreurs? Pouvez-vous corriger des bogues sans connaissance spécifique du domaine, et le partenaire d'externalisation a-t-il cette connaissance? La partie de fixation est la plus simple la plupart du temps, c'est la partie d'analyse qui prend le temps. De mon point de vue, c'est une décision stupide.
la source
Je courrais loin, loin, très loin. Un développeur est toujours, toujours, toujours responsable de corriger ses propres bugs. Manger sa nourriture pour chien est un principe de base d'une bonne ingénierie.
De plus, la correction des bogues est aussi importante, peut-être plus que le développement. Je veux dire, le développement est l'écriture de code, les tests et le débogage / correction.
Ce que j'obtiens de cette société, c'est qu'ils traitent la correction de bogues comme une tâche de deuxième classe. Cela en soi est assez dérangeant et je remets fortement en question leur qualité de travail (et ergo, leur environnement de travail.) Plus inquiétant, c'est qu'ils délèguent ce qui pour eux est un travail de seconde classe à des travailleurs offshore. C'est plus inquiétant. Il y a clairement une stratification sociale inscrite dans leur processus d'ingénierie.
Un défaut est toujours à l'origine d'un changement, et généralement le bogue est la responsabilité de celui qui a introduit le changement. Qui mieux que l'expéditeur pour comprendre la nature du bogue et sa résolution?
S'il est délégué à travers le monde, comment s'assurer que l'auteur original est disponible pour l'ingénieur délocalisé?
Sera-t-il même disponible, laissant l'ingénieur délocalisé qui n'a rien d'autre qu'un arriéré de bugs et de délais, mais aucun soutien de la Métropole ? Quel type de correction de bogue une personne pourrait-elle espérer effectuer? Qui corrige ses bugs? Et qu'est-ce qui empêche les développeurs de Metropole d'apprendre via la correction de bugs post-mortem?
Il y a des connards dans tous les domaines. Cela est particulièrement vrai dans les logiciels. Comme c'est inévitable, votre seule option est de travailler avec des connards qui en savent plus que vous ou qui font les choses correctement. Cette entreprise ne semble pas correspondre à cette description.
En bref, fuyez.
la source
S'attendent-ils vraiment à ce qu'un tas de développeurs juniors off-shore puissent réparer un tas de code de développeurs seniors? C'est comme demander à une infirmière de vérifier tous les neuroligistes et de les refaire là où il a fait des erreurs. MAUVAISE IDÉE!
la source
Je serais préoccupé par la façon dont leurs employés connaissent réellement le code qu'ils développent.
Je me demande également la raison pour laquelle il y a suffisamment de bugs pour justifier les coûts supplémentaires que cela entraîne. Je m'inquiéterais également de l'avenir à long terme de l'entreprise, il existe de nombreux articles sur le Web qui prétendent que ces entreprises utilisent le même code pour plusieurs projets, même dans la même industrie.
La correction du code défectueux fait partie du processus d'écriture du code, il vous permet d'avoir une meilleure compréhension de ce que vous avez fait de mal il y a 6 mois, donc vous ne faites pas la même erreur, si un autre développeur corrige vos erreurs, comment éviter cela bug de se produire encore et encore?
la source
Cela ressemble vaguement à mon employeur précédent, à l'exception du bit "employeur potentiel". Ils ont perdu les développeurs à cause de l'attrition et en ont perdu trop pour prendre en charge les produits existants tout en ajoutant de nouvelles fonctionnalités requises par les modifications des lois et des réglementations (60% des revenus du bureau proviennent d'un produit basé sur VB6, et MS a déclaré que les temps d'exécution du VB6 ne sera distribué dans aucun système d'exploitation futur, ce sera donc comme lorsque Vista est sorti - une course folle pour réparer les choses). Les pouvoirs en place veulent rendre l'entreprise publique bientôt, donc ils privent tout le monde de ressources pour rendre le bilan plus beau qu'il ne l'est - donc l'embauche à l'étranger est le seul moyen même de se rapprocher de rester sur le marché.
D'après mes expériences, ce que dit la citation est que votre employeur potentiel est bon marché.
la source
Cela dépend de ce qu'ils entendent par "correction de bugs". Si cela corrige des bogues pendant le cycle de développement / test, alors c'est très étrange, c'est le travail des développeurs d'origine. Si, d'autre part, ils signifient qu'ils ont externalisé la maintenance d'un produit publié, ce n'est pas inhabituel et ce n'est pas quelque chose dont je m'inquiète.
la source
D'après mon expérience, le fait de faire appel à une équipe externe après le fait brûlera autant de temps que de corriger vos propres bugs - ils doivent être mis à jour et intégrés au processus de développement. Et puis gardé à jour en continu. La coordination est plus difficile que d'écrire du code.
la source
Si je vais travailler sur une base de code, j'aimerais avoir l'assurance que tous ceux qui ont des privilèges de validation sont raisonnablement compétents. Cela inclut un certain nombre de personnes en Inde, par exemple, mais pas celles qui sont généralement délocalisées.
De plus, la plupart de mes bogues se trouvent dans des sections de code plus compliquées, et ce sont ceux que le programmeur offshore est le moins susceptible de comprendre avant d'appliquer une correction de bogue.
la source
Cette politique existe en fait inconsciemment dans certaines entreprises. Je travaille pour un donneur d'ordre; mes collègues et moi-même sommes des programmeurs plus compétents que les gars sur place, ils nous demandent de leur apprendre à utiliser des outils, etc., mais l'autre côté est que nous décelerons les problèmes dans leur code plus rapidement qu'eux.
Généralement, les programmeurs du client sont physiquement situés dans le même bâtiment qu'au moins certains des utilisateurs, de sorte qu'ils sont plus susceptibles d'obtenir un contexte qui ne s'étend pas à travers les hémisphères. Nous trouvons que cela fonctionne bien, la partie manquante pour moi est qu'ils ne révisent pas notre code, donc lorsque le contrat se termine, ils peuvent avoir des surprises ou des questions, non pas à cause de pratiques de mauvaise qualité de notre part nécessairement, mais juste les problèmes habituels que vous avez lorsque reprendre le projet de quelqu'un d'autre.
En tout cas, je suis heureux que dans notre cas, ce ne soit pas une politique officielle, en tant que telle, je pense que cela éroderait les programmeurs sur site en étant un peu plus que des BA.
la source