Quelles sont les pires fausses économies en développement de logiciel? [fermé]

126

Quelles sont les pires fausses économies (moyens d’économiser de l’argent qui coûtent finalement plus que ce qu’elles économisent) qui prévalent dans l’industrie du logiciel et comment les combattre?

Jon Hopkins
la source
2
:( j'en ai vu beaucoup trop souvent.
Tony
@ Casey: C'est un peu lié, mais pas entièrement. Le lien que vous avez donné concerne directement l'argent, tandis que les réponses à cette question concernent également l'argent et les croyances. Exemple, voir ma réponse: programmers.stackexchange.com/questions/19573/…
Gan
Vous venez de rendre visite à mon entreprise… tant
pis
1
@Mark - semble être une bonne question, allez-y. Un peu plus de détails pourrait être bon cependant.
Jon Hopkins

Réponses:

182

Dette technique

ie "Fais-le vite, on refactorera plus tard". D'abord parce que je n'ai pas encore vu quelqu'un se livrer à ce comportement en fait plus tard. Deuxièmement, parce que faire les choses rapidement, au lieu de choisir le bon, rend plus difficile l’ajout de nouvelles fonctionnalités ou la résolution de futurs bugs, de sorte que vous perdez du temps à long terme.

Malheureusement, beaucoup pensent encore que cela évite aux développeurs de faire quelque chose de rapide. Je suppose que c'est possible, mais je ne l'ai pas encore vu dans la pratique.

Inaimathi
la source
2
Je ne peux pas compter le nombre de fois où j'ai vu la direction arrêter les développeurs (2 à 3) pendant une journée, puis un spécialiste en déploiement pour réparer quelque chose (et le faire plusieurs fois au cours du cycle de vie du produit) au lieu de dépenser 2- 4 jours pour le faire correctement. Très bonne réponse.
DevSolo
4
Si le temps nécessaire à la résolution du problème est mesurable en dollars, par exemple la correction d’un bogue d’un système de négociation d’actions, la décision de la direction sera alors axée sur une réduction des coûts. J'ai trouvé que proposer de "corriger le problème maintenant pour le maintenir en fonctionnement pendant que nous déterminions le correct correct pour nous assurer que cela ne se reproduise plus jamais" répond à l'urgence motivée par les coûts et permet également d'obtenir le bon résultat, mais vous devez parfois vous battre pour cela. .
JBRWilkinson
9
Nous avons du code partout avec des commentaires comme "Ceci est un hack, remplace après la démo" qui est dans la base depuis 3 à 5 ans maintenant. Personne ne se souvient même que cela a été fait à ce stade, donc personne ne le trouve jusqu'à ce que quelqu'un (moi) corrige des bogues et le traverse. Inutile de dire que cette leçon d’objets m’a très bien appris à bien le faire la première fois si je suis en mesure de le faire.
CodexArcanum
22
Et honnêtement, je suis continuellement choqué par le nombre de fois où cela ne permet même pas de gagner du temps à court terme!
PeterAllenWebb
6
@ Jorg - Hein? «Dette technique et dette de conception sont des métaphores néologistes synonymes se référant aux conséquences éventuelles de l’architecture logicielle simpliste et du développement logiciel rapide. en.wikipedia.org/wiki/Technical_debt C'est précisément ce dont je parle. Un titre plus spécifique aurait peut-être été "Engager une dette technique sans intention de le rembourser", mais beaucoup de personnes se trouvant dans cette situation se disent elles-mêmes leur intention de rembourser (mais ne le font pas), et je voulais un titre percutant à placer texte en gras en haut. "Dette technique" semblait être un assez bon résumé.
Inaimathi
163

Embaucher 2 développeurs bon marché au lieu de 1 vraiment génial. (pour le même prix)

utilisateur2567
la source
9
Celui-ci au moins semble avoir une base dans la réalité; Gardez à l'esprit que les personnes non techniques ne peuvent pas dire qui sont les grands développeurs (ils sont donc très susceptibles de payer deux fois plus à un imbécile consultant aléatoire qu'à une superstar réelle).
Inaimathi
112
Ou malheureusement, je viens de louer un bon marché ...
DevSolo
4
... ou embaucher un gourou où deux mannequins feraient le 1.5 de ce que le gourou fait pour 1.0 du salaire du gourou: /
bobah
14
Vous n'obtenez pas 75% d'un gourou d'un mannequin , et tout bon programmeur fera ce qui est nécessaire sans être snob.
Peter Boughton
8
Les programmeurs 10x ou 100x offrent un rapport qualité-prix incroyablement incroyable; ils ne sont payés que 1,5, voire 2 fois. Comme le dit Michael Lopp (Rands in Repose), si vous n'en embauchez qu'un dans votre carrière, c'est une victoire nette.
Tim Williscroft
85

Mon exemple serait tout le contraire de celui de NimChimpsky , à savoir:

Essayer de développer en interne quelque chose qui peut être acheté sur le marché.

Normalement, cela s’explique par le fait que le marché n’a pas été vérifié pour vérifier s’il existe déjà quelque chose qui résoudrait le problème. Cela peut être aggravé par les développeurs qui aiment "plonger" dans le codage avant de faire des recherches et par les gestionnaires de projets qui ne tiennent pas compte de cette période = argent.

L'un des exemples les plus courants que j'ai vus dans mon domaine, le développement Web, concerne les entreprises qui tentent de développer un système CMS interne. Celles-ci commencent toujours par petit, mais deviennent vite gonflées et incontrôlables au fur et à mesure que les fonctionnalités sont verrouillées, alors que tout le temps, il y a beaucoup de produits gratuits et de frameworks qui seraient beaucoup mieux adaptés.

Dan Diplo
la source
17
Ce n'est pas parce que ça peut l'être que ça devrait l'être. Un CMS de base, ben ouais pourquoi réinventer la roue. Mais lorsque vous commencez à parler de systèmes à grande échelle et de la modélisation de processus métier complexes, pourquoi essayer de placer une cheville ronde dans un trou carré? Surtout si vous avez des développeurs et des compétences en interne.
NimChimpsky
9
@NimChimpsky - Je pense qu'il existe des exemples valables des deux. J'ai certes vu des personnes casser leurs processus métier et perdre des avantages en essayant de les adapter à des logiciels standards, mais j'ai également vu des développeurs souffrir de "problèmes non inventés ici" qu'ils auraient pu télécharger parce que c'était plus intéressant pour eux.
Jon Hopkins
3
@NimChimpsky Si la spécification nécessite un développement sur mesure, alors c'est très bien - cela nous maintient dans les emplois :) Le problème survient lorsque les gens ne vérifient pas au préalable si quelque chose est déjà développé correspond au projet et se lance directement dans le développement. Un peu de recherche peut aller très loin!
Dan Diplo
6
Pourquoi réinventer la roue? Parce que tu es un ingénieur de roue. Ou parce que votre roue est meilleure que celle du prochain. Ou parce que la roue ne va pas. See: mostmaths.net/2010/03/…
Derek
2
Là où je travaille, presque tout peut être acheté OTS - et presque tout est réinventé en interne parce que, selon nos Leaders Fearless (tm), "notre environnement est si complexe que rien sur le marché ne peut le supporter". Pfeh! Mais qu'est-ce que c'est bon - ça paie les factures. Nous avons appris hier qu'un composant majeur de notre logiciel sera réécrit l'année prochaine - AVEC UNE INTERFACE GRAPHIQUE! Ooooooh-aaaaaaah! Je suis tous un twitter ... (<pheh!>)
Bob Jarvis
73

Pas de ressources dédiées à la gestion de projet

Plusieurs fois, quelques programmeurs ont été embauchés et quelqu'un qui a déjà une journée de travail exigeante aurait dû gérer le projet, mais en réalité était trop occupé par d'autres tâches pour que le projet ne prenne jamais vraiment son élan. Les programmeurs ont fabriqué des "prototypes" et d'autres choses, mais sans avance, une bonne partie tournait en rond pour paraître occupée.

Mauvais équipement pour les nouveaux programmeurs

Une fois, j’ai connu une entreprise où la politique était la suivante: "les nouveaux programmeurs doivent travailler sur un très vieux PC avec un petit écran jusqu’à ce qu’ils prouvent qu’ils en sont dignes". Il n’est donc pas surprenant qu’une telle politique ait entraîné une sélection négative qui a eu raison de ceux qui ont toujours le choix de travailler dans un environnement plus sain.

utilisateur281377
la source
19
+1 Ne pas fournir un bon équipement à vos employés a "inévitablement échoué".
Terence Ponce
3
+1 Cependant, notez ce qui suit: dans de nombreuses entreprises, les budgets matériels relèvent de l’infrastructure et sont séparés des budgets de développement. Le gestionnaire d'infrastructure ne va pas toucher son budget pour alléger son budget. J'ai vu cette politique méchante jouer plusieurs fois.
Fil
3
Que diriez-vous du mauvais équipement pour TOUS les programmeurs? Mon ancien employeur nous a versé des salaires dans la Silicon Valley pour écrire du code sur des ordinateurs de bureau médiocres cinq ans auparavant. En raison de la brièveté des délais, ils ont licencié la moitié du personnel il y a un an et la majeure partie du reste en juillet - mais bon sang, ont-ils économisé de l'argent sur l'équipement!
Bob Murphy
1
Kaz: Chaque développeur devrait avoir une machine adéquate. Si acheter du nouveau matériel signifie que le PC du nouveau développeur est un peu meilleur que celui des autres développeurs, eh bien, dans le pire des cas, vous avez des machines swap si elles sont du genre à pleuvoir. Les gens normaux ne s'en soucient tout simplement pas tant qu'ils ont l'équipement qui leur permet de travailler efficacement. À l'endroit où je travaille actuellement, j'ai un PC plus récent (probablement plus rapide) que celui qui m'a embauché. Les personnes qui sont venues après moi ont des PC encore plus récents, probablement plus rapides. Devine quoi? Personne ne s'en soucie, car toutes nos machines sont assez rapides.
user281377
3
Lorsque le matériel est insuffisant, je tiens à le signaler à la direction, généralement en effectuant un travail utile, tel que couper les ongles des pieds ou lire le document lors de longues compilations. J'ai la vieille machine lente? Bien sûr, pas de problème. Oh, tu as un correctif de bogue et je dois faire la compilation? Chose certaine, monsieur le directeur, bwana-sahib-mec - à tout à l'heure! (Un jour, un responsable m’a demandé ce que j’avais fait toute la journée. Je lui ai dit: "Re-construit l’application. Quatre fois". "Dans huit heures?!?", Cria-t-il. Cela a pris 10 heures ". Une nouvelle machine est arrivée peu de temps après ... :-)
Bob Jarvis
71

Nous pouvons économiser de l'argent en faisant en sorte que les programmeurs jouent le rôle de testeurs / rédacteurs techniques.

Si vous payez des salaires de programmeur pour le travail de testeur / rédacteur technique, vous gaspillez de l'argent et obtenez un travail de qualité inférieure à celui d'une personne qui a consacré sa carrière à cette tâche. En outre, lorsqu'un programmeur est confronté à une échéance serrée, les tests et la documentation risquent fort d'être abandonnés ou compliqués pour le respecter.

BTW: Les développeurs sont TOUJOURS confrontés à une échéance serrée.

JohnFx
la source
12
Les gens intelligents peuvent faire n'importe quoi bien erreur.
Jon Hopkins
3
J'ai saisi des données, même si je n'allais certainement pas baisser mes tarifs. Ils voulaient quelqu'un qui soit rapide et précis pour certaines entrées de données critiques, et cela ne les dérangeait pas de payer au moins trois fois les taux de saisie de données. Leur choix.
David Thornley
1
Je dirais que c'est le travail des programmeurs de tester leur code, mais je ne sais pas si c'est de cela que vous parliez.
Ben Lakey
3
Les programmeurs doivent tester leur propre code, sans exclure la présence de testeurs dédiés, professionnels du traitement des logiciels.
JohnFx
1
D'accord sur la rédaction technique, pas d'accord sur les tests. Tester est un élément naturel de l’écriture d’un bon logiciel. La rédaction technique est tout simplement un changement trop important du codage. Je trouve que je dois changer beaucoup de vitesse pour passer du codage à la rédaction technique, ce qui me fait penser à une mauvaise utilisation de mon temps.
Adam Bruss
63

Le code de recherche / lecture / écriture non lié au développement du produit est un gaspillage de ressources.

Certains programmeurs et même des gestionnaires y croient. Normalement, ils ne font que programmer en se basant sur les connaissances de leur tête, puis effectuent des recherches et cherchent des réponses quand ils rencontrent des problèmes. Ils n'améliorent pas continuellement leurs connaissances de manière proactive. À mon avis, nous devrions toujours nous tenir à jour et les connaissances que nous avons rassemblées nous seraient utiles pour résoudre les problèmes actuels et futurs. Bien sûr, vous devez utiliser votre temps judicieusement pour le faire.

Ceci est également similaire à la réponse de Dan . Certains gestionnaires souhaitent simplement que les développeurs se plongent rapidement dans le produit et le développent en fonction des besoins, sans rechercher les produits existants sur le marché.

Gan
la source
3
J'aurais aimé pouvoir voter plus d'une fois.
MAK
1
Permet d'écrire une bibliothèque graphique. Permet de construire une boîte à outils de messagerie. Si vous ne vendez pas le logiciel, ce n'est qu'une partie d'une chose plus importante. Pour l'amour du ciel, utilisez simplement la mise en œuvre de quelqu'un d'autre. Points de sécurité pour l'utilisation d'une solution open source, vous pouvez toujours la corriger et la prendre en charge si vous devez le faire. Si vous avez l'argent pour acheter des solutions avec source incluse, faites-le, mais méfiez-vous de la mauvaise qualité des composants logiciels commerciaux. Les vendeurs vous vendent rarement le composant deux fois. Vous risquez donc d'être déçu une fois que vous en êtes le propriétaire (je sais que j'ai déjà travaillé dans des endroits mordus auparavant)
Tim Williscroft
58

Dans de nombreux cas, la délocalisation coûte plus cher. Dans mon entreprise, il est très difficile d’obtenir de nouveaux postes vacants, nous sommes poussés à externaliser. Il est également difficile de faire appel à des entrepreneurs sur site. il y a un ratio de 3: 1 offshore / onshore qu'ils sont supposés maintenir. En conséquence, beaucoup d’équipes ne recrutent qu’une douzaine de sociétés offshore et ne les utilisent pratiquement pas, de manière à pouvoir engager 4 contractants sur site.

Jeremy
la source
18
+1 D'après mon expérience en matière de délocalisation, cela coûte inévitablement beaucoup plus d'argent que d'économiser.
Adam Crossland
2
+1, mais l'offshore peut fonctionner s'il est utilisé correctement
3
+1 Il semble que nous ayons des développeurs off-shore différents pour chaque nouveau projet, ce qui signifie que les développeurs on-shore passent la plupart de leur temps à enseigner aux nouveaux développeurs offshore le modèle de domaine métier et technique, en plus de fournir un support technique. Fin du projet et ils sont partis ailleurs et nous recommençons avec la prochaine série de développeurs «bon marché».
Chris Knight
8
beaucoup d'équipes embauchent juste une douzaine de sous-marins et les utilisent à peine, juste pour avoir 4 contractants sur site. Sensationnel.
poolie
1
Et oublier que les délocalisations vont, par nature, prolonger le délai. Nous avons l'assurance qualité à l'étranger et cela peut prendre 3 à 4 jours pour résoudre un problème que deux personnes dans le même bureau pourraient effectuer en moins d'une heure en raison de différences de temps.
HLGEM
50

Longues boucles de rétroaction!

Cela arrive à tout le monde: vous construisez quelque chose que vous trouvez génial, et vous vous êtes trompé. Ce n'est pas le problème. Le problème est combien de temps vous passez à construire avant de découvrir que vous devriez arrêter.

Au niveau supérieur, vous voyez ce problème avec de longs cycles de publication. Si vous construisez pendant un an sans retour, vous jouez toute l'année. Plus vous relâchez de coups, plus vous jouez petit et meilleur vous êtes au jeu.

Mais cela se produit aussi aux niveaux les plus bas. En tant que développeur, j'aime beaucoup les revues de code fréquentes (ou, mieux, la programmation en paire), car cela limite le temps pendant lequel je peux continuer à faire quelque chose de stupide avant que quelqu'un ne dise: "Hé, il existe un moyen plus simple!" Pour la même raison, j'aime que mes tests unitaires soient exécutés rapidement et fréquemment afin de pouvoir attraper et tuer les bugs avant qu'ils ne grossissent.

Une fois que vous commencez à remarquer l’importance des boucles de rétroaction courtes, vous le verrez partout. Par exemple, la notion militaire de la boucle OODA .

William Pietri
la source
6
+1 Aussi: plus la boucle de rétroaction est longue, moins vous vous souvenez de la tâche. À l'extrême, vous devez vous familiariser à nouveau avec l'intégralité de la base de code.
Joseph Tanenbaum
Comment est-ce une fausse économie? Quelle est l'économie prévue?
Chris Pitman
Le but est de gagner du temps "perdu" sur les choses que vous faites à chaque boucle. Par exemple, créer, tester, publier, prêter attention aux utilisateurs. C'est l'excuse, de toute façon. Je pense que c'est vraiment enraciné dans éviter le malaise.
William Pietri
C'est pourquoi il est impératif que les examinateurs et les partenaires à deux aient humilité et respectent le codeur autant que possible. Un examinateur gênant qui traite mal le codeur et vous pouvez garantir que la boucle de rétroaction augmentera considérablement.
Jonathan Neufeld
47

Ce n’est pas ma propre anecdote, mais j’ai déjà entendu parler d’un magasin qui ne fournissait plus de café gratuit à ses développeurs, leur disant que chaque fois qu’ils voulaient prendre un café, ils étaient libres de se rendre au café le plus proche (environ 10 minutes). aller et retour) et en acheter.

À peu près la définition de la fausse économie.

EricBoersma
la source
4
C'est assez spécial. Comparez et contrastez avec certaines des banques commerciales de Londres qui ont fait construire un bâtiment subventionné avec Starbucks afin de réduire le temps nécessaire pour aller prendre un café.
Jon Hopkins
48
Je ne suis pas d'accord pour dire qu'il s'agit automatiquement d'une fausse économie: les 10 minutes d'air frais que vous marcherez à l'extérieur pour acheter le café oxygèneront l'employé et en amélioreront la concentration. De plus, les interactions sociales (bien que limitées) réduiront la dépression, en particulier en hiver. Les employés qui n’obtiendront pas de café parce que ce n’est pas gratuit, rentreront probablement chez eux à l’heure, auront plus de sommeil et seront en meilleure santé grâce à leur consommation réduite de caféine.
JBRWilkinson
6
-1, une promenade de 20 minutes est parfaite pour libérer votre esprit et donner une nouvelle perspective au problème.
Malfist
23
@ Malfist: Si j'ai bien compris, ce n'était pas seulement 20 minutes de marche, mais aussi 15 minutes d'attente pour avoir le café qui a interrompu le travail. Une pause de 45 minutes à n'importe quel moment de la journée va sensiblement détruire la productivité pendant bien plus d'une heure et demie. Tout cela pour économiser 100 dollars par mois sur le café.
EricBoersma
8
20 + 15 = 35 [six autres personnages]
Malfist
47

Fournir des postes de travail à écran unique, car un deuxième moniteur est trop coûteux . Même si cela ne vous fait gagner qu'une heure de travail chaque année, un deuxième écran reste un bon investissement. Je sais avec certitude que le mien m'a sauvé de nombreuses heures de travail.

Une configuration multi-moniteurs peut rendre presque n'importe quelle tâche plus efficace, pas seulement les tâches de développement. Trois moniteurs sont encore meilleurs que deux, mais l'effet devient moins prononcé avec chaque écran supplémentaire.

Configurations multi-moniteurs:

  • diminuer le temps de commutation de la fenêtre
  • vous permet de garder un œil sur les éléments en arrière-plan (courrier, compilation, etc.).
  • vous donner un sentiment de liberté. C'est comme être dans un atrium ou dans un placard à balais.
  • etc...
Arjen Kruithof
la source
2
A été confronté exactement à cette question une fois. Un courrier adressé à l'un de nos PDG, calculant explicitement qu'avec une efficacité accrue de 5%, j'aurais économisé une somme d'argent digne du moniteur en environ un mois et demi par rapport à mon revenu net. Ce calcul était à peu près irréprochable ... mais ... je suppose que vous connaissez déjà la fin de l'histoire :)
Raffael le
39

Le matériel le moins cher est confié à un consultant lorsque celui-ci coûte plus de 150 $ / heure .

Mettre en perspective un meilleur matériel peut au moins rendre le travail 30min plus efficace par jour. Cela donnerait 30 minutes * 20 jours de travail par mois = 600 minutes / mois = 10 heures / mois> plus d'un jour de travail = 10 heures * 150 $ / heure = 1500 $

Maintenant, un consultant ne travaillerait-il pas plus efficacement s'il disposait d'un ordinateur à 1500 $? Le consultant serait-il moins irrité?

Maintenant, le problème semble être qu'il existe deux budgets, un pour le consultant et un pour le matériel informatique.

Amir Rezaei
la source
8
En tant que consultant, je suis allé là-bas, j'ai fait le t-shirt. (Seulement 80 $ de l'heure, cependant.) Mais bon, c'est une des raisons pour lesquelles j'aime les contrats horaires. Contrairement à un poste salarié, si un client consultant décide de perdre mon temps et que je dois travailler plus pour le rattraper, c'est plus d'argent dans ma poche.
Bob Murphy
2
Sans vouloir vous offenser, mais si je paie 150 USD / heure pour un consultant, il ferait mieux de disposer de son propre ordinateur.
Steven Evers
8
@SnOrfus: Cela ne fonctionne généralement pas dans l'environnement d'entreprise, où il existe un contrôle strict des PC autorisés sur le domaine. Vous devez leur fournir du matériel.
HardCode
1
@ HardCode - Oui, je suppose. Je peux voir le point maintenant.
Steven Evers
3
@HardCode Sur un projet récent, au lieu de nous ajouter (entrepreneurs) à leur réseau d'entreprise interne, ils nous ont mis en quarantaine sur notre propre ligne DSL. Une ligne DSL dédiée pour 3 développeurs à hauteur de 40 USD par mois représente un changement radical et nous permet de transmettre facilement les mises à jour à distance sans paniquer le personnel informatique. De plus, si le PC de production exécutant notre code est infecté et se bloque, c'est de notre faute, car nous sommes responsables de la sécurité de nos communications et de nos ordinateurs portables personnels. Pouvez-vous dire gagnant-gagnant-gagnant.
Evan Plaice
38

Des mois de travail épargnent des jours de planification

(Ne pas investir assez de temps dans la planification)

serg
la source
21
À la fin de ses études universitaires, on disait que quelques semaines passées au laboratoire peuvent vous faire gagner une heure de temps en bibliothèque.
David Thornley
7
Ouaip. Lorsque je suivais un cours de premier cycle en laboratoire où nous avions identifié des produits chimiques inconnus, le prof nous a dit "une heure dans la bibliothèque vous en épargnerait quatre dans le laboratoire". Je le prenais au sérieux et il était hilarant d'entrer dans le laboratoire une heure par semaine et de recevoir des regards désagréables des médecins qui passaient douze heures par semaine à tester des amines sur des composés qui n'étaient clairement pas des amines. Et quand j’ai enseigné le même laboratoire plusieurs années plus tard, j’ai donné le même conseil aux étudiants, et peu d’entre eux l’ont réellement suivi.
Bob Murphy
3
Si vous ne parvenez pas à planifier, vous prévoyez d'échouer
27

Je soupçonne surtout que les gestionnaires ne fournissent simplement pas aux développeurs les outils dont ils ont besoin pour faire leur travail efficacement.

Fondamentalement, le point 9 du test de Joël .

richeym
la source
2
J'ai participé à des projets où ils nous feraient perdre une semaine ou deux au lieu d'acheter, par exemple, une bibliothèque à 300 dollars avec le travail déjà fait - et mieux (nous ne sommes pas des "développeurs de contrôle" sur lesquels je travaille.) Ou choisissez un outil logiciel "parce qu'il est fabriqué par" telle ou telle "entreprise" au lieu de chercher s'il existe de meilleures alternatives, faites de notre vie un enfer pendant des années.
MetalMikester
J'ai moi-même rencontré celui-là. Le raisonnement PM / client était que nous n'avions pas de poste budgétaire pour acheter des articles pour le client (les changements de contact étaient une salope), de sorte que nous devions réinventer la roue (à nouveau).
Ken Henderson
24

"Jeter (assez) de corps sur le problème" peut encore être utilisé à certains endroits, malheureusement. La loi de Brook s'oppose à cela dans The Mythical Man-Month , bien que certains aient besoin d'expérience pour apprendre cette leçon. En général, ce n’est pas quelque chose en mon pouvoir qui m’arrête, car la direction peut croire la fausse déclaration selon laquelle il faudrait ajouter des personnes et ne pas en payer le prix.

JB King
la source
2
+1 Oh mon dieu oui. Cela se passe actuellement à une échelle épique sur un projet majeur où je travaille.
Bobby Tables
3
Je travaille avec un groupe de chefs de projet, de gestionnaires, etc., qui ont tous leur certification en tant que projet de gestion de projet (quel que soit le nom), et PERSONNE n'a jamais entendu parler de The Mythical Man-Month avant de les présenter. à cela. Sheesh!
Bob Jarvis
2
J'ai entendu une bonne citation à ce sujet: 9 femmes ne peuvent pas avoir de bébé en un mois
Richard
@ Richard je l'ai utilisé lors d'une réunion. m'a fait un immense plaisir!
Tjaart
21

Réunions quotidiennes :

(meeting duration in hours) x (Y team members) x (average salary per hour) = ...  
Zzz
la source
9
Avoir rencontré juste pour le plaisir de rencontrer ...
Gan
5
Ordre du jour pour aujourd'hui: quel sera l'ordre du jour de la réunion de demain?
Marc C
9
Les réunions quotidiennes sont acceptables si elles sont courtes. Des réunions debout de type Scrum de 3 minutes ne vous font pas perdre beaucoup de temps, mais tiennent chacun au courant des développements de chacun. Les longues réunions avec de nombreux participants désintéressés sont toxiques, cependant.
9000
3
@Mark C - Cela peut sembler une blague, mais j'ai en fait été invité à des réunions pour planifier ce que serait l'ordre du jour de la réunion des prochains jours ...
Gavin Coates le
@Gavin Coates c'est une réalité et la situation ... :)
Zzz
20

Acheter un logiciel standard au lieu de le développer en interne.

J'ai une expérience des systèmes de gestion à l'échelle de l'entreprise, axée à la fois sur les laboratoires de ressources humaines et biologiques.

Une solution prête à l'emploi coûtait entre 50 et 100 000 £ et nécessitait un développement et une personnalisation supplémentaires pour répondre aux besoins de l'entreprise.

La solution développée en interne a pris (moins de six mois) à développer, tandis que d’autres projets étaient traités en parallèle et utilisait un développeur déjà employé.

Je suis passé du secteur public où nous avions un système de gestion de l’information de laboratoire (LIMS) développé en interne à un grand groupe pharmaceutique international où la mise en œuvre d’une solution standard avait pris plus d’un an et n’était nulle part achevée.

(6 mois d’un développeur déjà engagé travaillant sur d’autres projets en parallèle. So ~ 10k. Et cela n’inclut pas les coûts de support associés à la solution hors plateau). Le point majeur est que le système développé en interne était réellement utilisé! Vous avez donc un avantage de coût supplémentaire, que je ne peux pas calculer.

Je serais d'accord pour les sites Web de base, etc., pourquoi se donner la peine de développer les vôtres? Mais pour tout grand système complexe et si vous avez déjà des compétences internes, je le construirais moi-même .

NimChimpsky
la source
26
Je parie qu'il y a aussi beaucoup d'exemples de l'inverse.
Jon Hopkins
13
Acheter ou développer revient aux bonnes personnes qui font preuve de diligence raisonnable. Aussi simple que cela. Pense avant d'agir. (+1)
DevSolo
4
@DevSolo: spot on. La décision de construire ou d'acheter devrait être étayée par une analyse coûts-avantages, plutôt que par une attitude émotionnelle «pas inventé ici» ou «j'aime le logiciel de XXX».
JBRWilkinson
9
Si vous voulez faire une déclaration générale sur la construction par rapport à l'achat, vous devriez le faire: préférez acheter des solutions à des problèmes qui ne font pas partie des compétences de base de votre entreprise. Ce n'est pas toujours la bonne réponse, mais c'est une position par défaut raisonnable, et aussi fiable qu'un cliché peut l'être. Dire que l'achat de logiciels sur étagère est une fausse économie, cependant, n'est même pas un cliché utile. '). Mais la présence de mauvaises options ne signifie pas qu'il n'y en a pas de bonnes.
evadeflow
2
Je pense que le problème est d’acheter et qu’il faut encore plus de développement et de personnalisation . Le coût d’un peu de personnalisation sur un grand système introduit peut souvent être plus que l’écriture de votre propre petit système qui fait juste ce que vous voulez. Donc, achetez si vous pouvez travailler comme le système que vous achetez vous attend, mais acheter et personnaliser peut donner le pire des deux côtés!
Ian
15

Acheter des produits coûteux prêts à l'emploi lorsque les alternatives open source sont meilleures et gratuites.

Combien d'entreprises utilisent git? Combien de sociétés utilisent des systèmes de contrôle de version entreprise de merde?

hasen
la source
1
Euh, cela peut-il être considéré comme la "pire fausse économie"? Ou probablement vous avez besoin d'élaborer plus ...?
Gan
3
Je ne suis pas tout à fait d'accord avec l'exemple du contrôle de source, à tout le moins. Git a été spécialement conçu pour résoudre les problèmes liés aux sources ouvertes: nombreux développeurs, faible contrôle central, nombreuses succursales, etc. flux de travail, etc.
PeterAllenWebb
1
@Gan: Ils pensent que l'utilisation de l'open source est une fausse économie, mais ils ont tout en arrière.
Hasen
3
Je contribue à X11 et à GNOME et je suis assez compétent pour utiliser git et administrer des serveurs gitosis. Néanmoins, cet été, j'ai remplacé mon travail de consultant par un serveur Perforce payé personnellement, car il effectue automatiquement de nombreuses tâches que vous devez effectuer manuellement avec git. Étant donné que je suis payé pour la livraison de code et non avec le contrôle de version, utiliser et payer pour un "contrôle de version de mauvaise qualité" est bien plus économique que d'utiliser git.
Bob Murphy
7
Selon mon expérience, l’open source et les produits commerciaux constituent vraiment une base de "cas par cas".
MetalMikester
14

Utiliser des langages "simples" sans grande expressivité

Oui, il est plus facile pour les programmeurs de gérer le code, mais plus difficile de trouver de bons programmeurs qui n'apprennent pas seulement le dernier mot à la mode qui les engagera. Oui, cela rend le code individuel plus facile à comprendre, mais le rend aussi rigide qu'un 2x4 et augmente le volume de code à comprendre. Oui, il est soutenu par une énorme société, mais cette grande société innove lentement et bureaucratiquement.

Dsimcha
la source
4
@burnt_hand: Je parle essentiellement de l'aversion excessive au risque de la direction en termes de choix de langue.
dsimcha
1
+1: Continuez simplement à utiliser C car "nous possédons ces compétences et nous apprenons un nouveau langage sophistiqué comme Python / Perl / PHP qui ajoute beaucoup de risques". Entendu plus d'une fois. Cela signifie-t-il que l'équipe est trop stupide pour apprendre une nouvelle langue?
S.Lott
1
@ S.Lott Les agents de recrutement pensent que vous l'êtes !, mais c'est une autre histoire
burnt_hand
2
C'est-à-dire que les entreprises qui utilisent Java et C # et qui ont trop peur de toucher Python ou Ruby, car elles ne sont pas "standard", ce qui me rappelle: paulgraham.com/avg.html
hasen
1
@hansen: L'essai de Paul Graham est en partie ce qui m'a inspiré pour écrire ce post. Mon autre inspiration a été mon travail de développement de bibliothèques (y compris la bibliothèque standard) pour le langage de programmation D.
dsimcha
13

Mauvais chefs de projet / chef d'équipe.

Depuis une personne incompétente ont le pouvoir de ruiner le travail d'un groupe de personnes. Au final, le projet ferait beaucoup mieux sans les décisions de la haute direction (responsable du projet / de l’équipe).

Dose le "Fais-le vite, on refactorera plus tard" décide.

Amir Rezaei
la source
4
Je conviens qu'il y a de mauvais gestionnaires, mais "le projet ferait beaucoup mieux sans les décisions de la direction"? Généralement, ce sont les personnes qui parrainent le projet. Cela me semble un peu comme les développeurs que j'ai rencontrés qui pensent qu'il est plus important de comprendre la technologie que de comprendre l'entreprise et d'oublier qui est le client réel.
Jon Hopkins
2
@ Jon Hopkins Avec la haute direction, je ne réfère pas le client. Le problème, c’est que les «mauvais chefs de projet» sont ceux qui commettent des erreurs après des erreurs et s’opposent à un groupe de personnes. Qui pensez-vous décider "Fais-le vite, on refacturera plus tard". Lisez la réponse avec le taux le plus élevé!
Amir Rezaei
ah, plus clair. Je retire mon -1.
Jon Hopkins
J'ai remarqué une tendance inquiétante de la part des chefs de projet qui reverraient le temps et les coûts sur la qualité. Je suis sûr que je ne suis pas le seul. Les chefs de projet aiment utiliser le diagramme en triangle avec coût / qualité / temps, mais la qualité commence toujours par démarrer. C'est très triste, et institutionnaliser et forcer les métriques de gestion de projet (PMI) sur quelque chose d'aussi compliqué que le logiciel ne semble qu'aggraver les choses.
Bernard Dy
1
@ Bernard - le temps et le coût sont mesurables. Qualité? Pas tellement. Triste mais vrai OMI ...
Bob Jarvis
12

Besoins utilisateur manquants

Une étape importante et difficile de la conception d’un logiciel consiste à déterminer ce que le client souhaite réellement faire.

Croyez-le ou non, parfois cette partie manque ou est obsolète. Ce qu’il en coûte, c’est que l’on crée des fonctionnalités que l’utilisateur final n’a jamais demandées.

Amir Rezaei
la source
Je pense que cela devrait être au top!
Roopesh Shenoy
8

La productivité vaut plus que la créativité

La créativité est difficile à mesurer en général, et le plus souvent impossible même à observer, peu importe la mesure, en matière de développement de logiciels. La productivité, en revanche, peut être mesurée (souvent de façon médiocre) et peut être observée.

En conséquence, les développeurs qui sont plus productifs (écrivent plus de lignes de code | écrivent du code plus vite | récitent plus rapidement un technobable en réponse à des questions | sont plus productifs) ont tendance à être plus valorisés que ceux qui (utilisent moins de lignes de code pour résoudre le même problème | prendre plus de temps pour écrire du code, mais produire un produit plus fiable | comprendre suffisamment le sujet pour répondre aux questions en clair, facile à comprendre, anglais | résoudre de manière créative les problèmes).

les bleuets
la source
6

Tous les éléments ci-dessous peuvent être mauvais s'ils sont utilisés ou non utilisés de manière inappropriée

  • logiciel externe vs interne

  • Conformité ISO 9001 (économie - atténuation du risque de perte du SMS si la qualité du produit diminue)

  • développement / assurance qualité

  • procédures de développement / build / release / support

bobah
la source
En quoi ISO 9001 est-elle une (fausse) "économie"?
Andrew Grimm
@Andrew Grimm - la conformité garantit un certain niveau de qualité qui atténue les risques résultant d'une mauvaise qualité (perte de MSS par exemple), de sorte qu'une économie potentielle soit clairement définie. Pour les petits ministères, cela peut être inapproprié car les pertes de frais généraux sont plus élevées que celles
dues à
1
@ Andrew - dans mon expérience, cela dépend de ce que vous voulez. Si vous souhaitez améliorer la qualité, il s'agit probablement d'une fausse économie, car elle a tendance à être coûteuse et peut être mal adaptée aux logiciels. Si vous le souhaitez comme un outil de marketing ou parce que vous vous y attendez dans votre secteur d'activité, c'est potentiellement une bonne idée.
Jon Hopkins
5
@Andrew Grimm - La seule "garantie" que garantit ISO 9001 est une qualité constante et reproductible. Cela ne garantit pas une "haute" qualité. Toutefois, si une qualification ISO 9001 est requise sur le marché dans lequel l'entreprise veut être, elle l'est.
Vatine
1
@Vatine: Ce que garantit ISO 9001 est un processus cohérent et reproductible. Dans certains domaines, où des processus cohérents produisent une qualité constante, c'est important. Cela ne garantit pas une qualité élevée, mais si un client voit quelque chose que vous avez bien fait et sait que vous êtes certifié ISO 9001, il sera confiant en une qualité similaire.
David Thornley
4

Avoir trop de gestionnaires de diffusion non facturables.

Il y a quelques années, dans notre entreprise, nous avions plusieurs projets à gros budget et le recrutement était à son apogée. A cette époque, notre société avait engagé trop de responsables de la livraison (dont beaucoup n'étaient pas des informaticiens!) Et très peu de programmeurs / testeurs. Le ratio gestionnaire / programmeur était littéralement de 1: 2. Plus tard, après l'achèvement de ces projets, nous nous sommes retrouvés dans une situation où beaucoup de ces gestionnaires (certains d'entre eux étaient de véritables fainéants) assis sur un banc ne rien faire. Nous avons eu un cycle d’évaluation où tout le monde n’avait que peu / pas d’augmentation (même les programmeurs assidus, soupir) afin que cette entreprise n’a pas à licencier qui que ce soit! Heureusement, la société a pris conscience de cette situation et a fait le RIGHTSIZING au premier trimestre de cette année!

Mananjani
la source
3

Optimisation avant le profilage (optimisation prématurée).

Trop souvent, j'ai vu quelqu'un arriver à une solution intelligente qui complique inutilement la maintenance et la lisibilité au motif qu'elle est plus rapide. Naturellement, le code n’a pas été évalué (pas même avec des micro-tests), il devient donc "plus rapide en se basant sur l’argument plus persuasif" d’une section de code qui n’a probablement pas eu d’incidence sur les performances globales. application de beaucoup.

En tant que telle, il s’agit d’une économie très fausse, et du genre de fausse économie qui enchevêtrent parfois même les plus chevronnés.

Edwin Buck
la source
3

Accès internet limité ou inexistant

Évidemment, vos employés utiliseront Internet pour jouer à des jeux sur Facebook sans trop chercher les réponses aux questions techniques sur Stackoverflow.

En réalité, bien sûr, Internet représente un énorme gain de productivité et, même s’il peut être approprié d’utiliser un filtre de site pour les sites réellement douteux, il ya un problème si le fichier readme de Visual Studio est bloqué ou si les pages du gouvernement local de Telford sont bloquées. "tourisme sexuel"

jk.
la source
2

Amener vos développeurs à utiliser un moniteur de 15 pouces et un PC aux spécifications peu contraignantes, car il s’agit du standard de l’entreprise.

Les moniteurs de taille raisonnable sont peu coûteux, rapides à installer et rendent les programmeurs plus productifs, tout en laissant penser à vos programmeurs que vous leur tenez à cœur.

Ian
la source
2

Trop de bacheliers en administration des affaires (ou assimilés), organisés hiérarchiquement, essayent d’appliquer ce qu’ils pensent de la gestion moderne: déranger les gens avec des "KPI", des "SLA" et autres, exiger des "rapports" (sans, bien sûr, s’occupant de l’infrastructure nécessaire pour les générer), de sorte que les programmeurs passent leurs journées à remplir des feuilles EXCEL, rapports T4 fantaisistes et autres contenus, et à les copier d’un nouvel outil de gestion et les coller dans ces outils ne sont jamais intégrés ni intégrables les uns aux autres) et assistent à des réunions où les rapports et les chiffres sont présentés (et tout le monde est culpabilisé d'avoir omis de remplir tel ou tel indicateur de performance clé).

Ingo
la source