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

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?

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.

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

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.

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.

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.

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é.

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.

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 .

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.

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...

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.

Des mois de travail épargnent des jours de planification

(Ne pas investir assez de temps dans la planification)

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 .

"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.

Réunions quotidiennes :

(meeting duration in hours) x (Y team members) x (average salary per hour) = ...  

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 .

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?

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.

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.

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.

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).

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

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!

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.

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"

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.

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é).