Études des coûts relatifs du développement dans différentes langues

Question

Quelqu'un a-t-il déjà vu une étude récente (et relativement équilibrée) sur les coûts relatifs du développement de logiciels utilisant des langages différents? Je voudrais en particulier voir les coûts relatifs de Java vs. C # vs. Delphes.

Answer 1

Pas de. Mais je ne suis pas fanatique de tout, et de travailler comme consultant et l'utilisation de recommander l'un d'entre eux pour chaque exigence que j'ai. Voici donc quelques faits pour rendre plus facile de choisir ce que pour contrer le développement du système les exigences que vous pouvez avoir.

En Commun:

Tous d'entre eux sont les meilleurs dans leurs domaines:

• Java est le meilleur de développement Java option.
• C# est le meilleur .NET option de développement.
• Delphi est le meilleur Natif option de développement.

Elles disposent toutes de:

• Dans le monde de vendeurs tiers qui fournissent des composants de qualité et des bibliothèques.
• Connues dans le monde entier des applications créées avec eux (par exemple en Delphi qui sont plus connues: Yahoo Go pour la TV!, Macromedia Captivate, TotalCommander, MediaMonkey, FinalBuilder, InstallAware, WinLicense, Administrateur MySQL, etc).

Tous d'entre eux sont:

• Très fiable technologies avec RAD capacités.
• Pris en charge par le meilleur développement des outils d'aide (UML, etc).
• Libérant d'importantes mises à niveau de ses technologies (Java 7, de .NET 4.0 et Delphi multiplateforme).

Différences:

3 Choses dont C#, c'est mieux:

• La quantité de développeurs disponibles (en comparant avec Java) qui peuvent le code (*).
• Microsoft a derrière.
• Moins chère des coûts de développement en termes de salaires (en général).

3 Choses dont Java est mieux:

• La quantité de développeurs disponibles (en comparant avec Delphi) qui peuvent le code (*).
• La portabilité.
• A Soleil derrière.

3 Choses dont Delphi, c'est mieux:

• Vitesse (meilleure performance pour temps des systèmes critiques).
• Faible encombrement (le compilateur Delphi génère de très petits fichiers binaires).
• N'a pas de dépendances explicites (en faciliter la distribution).

---

(*) il est très fiable fait qu'il y a plus d'autres langues que les développeurs peuvent le code en C# que d'autres-les langues-les développeurs qui peuvent le code en Java, ce qui signifie qu'il est plus facile de trouver C#, programmeurs. Cela explique peut-être pourquoi, dans de nombreux sites (comme celui-ci) et les forums qui permettent de multi-langue de questions, refactorings, etc, il ya GÉNÉRALEMENT plus de C# questions et réponses (84 vs 50k). Aussi, depuis Java emplois sont mieux rémunérés dans de nombreuses parties du monde, le sens commun souligne que les développeurs de Java restent plus longtemps dans leur emploi que C#, qui rend plus difficile de trouver des développeurs Java disponible qu'en C#. Et bien sûr, il ya d'autres facteurs qui peuvent être discutées, mais je suis sûr que c'est généralement plus facile de trouver un programmeur C# que Java.

Answer 2

Je ne sais pas à propos de ses études, mais j'ai entendu beaucoup de récits anecdotiques de sociétés en prenant une application existante en Delphi et de la réécrire en C# pour une raison ou une autre. Ils se terminent tous de la même façon.

Il a fallu deux fois plus long à réécrire le programme en C#, comme il l'a fait à l'origine de l'écrire dans Delphi, même avec toute la logique métier et la connaissance du domaine déjà travaillé et qui est présent dans la forme de l'existant, Delphi, base de code. Pendant ce temps, ils n'étaient pas diffuser des mises à jour, car toutes leurs ressources étaient occupés avec la réécriture, ce qui leur concours afin de gagner des parts de marché. Et quand elle a été faite, c'était de 1,0 au niveau du produit. Glitch, lent et difficile à utiliser, souvent avec de graves en arrière-problèmes de compatibilité.

La raison pour laquelle sont ouverts à l'interprétation, mais je pense que l'un des principaux facteurs qui rend Delphi donc beaucoup plus productif que de C# (ou Java) est la langue du regard et la sensation.

Il est de notoriété publique que beaucoup plus de travail, de temps et d'efforts dans le maintien et le débogage des programmes modernes qu'initialement wriitng, mais ce principe n'est pas souvent suivi jusqu'à sa conclusion logique. Si ce qui nécessite le plus de travail est de maintenir le programme, puis choisir une langue sur la base de facile ou rapide à écrire du code dans l'est de l'optimisation prématurée. Vous obtenez un meilleur retour sur votre investissement si vous utilisez un langage facile à lire et à maintenir. Et quand il s'agit de la lisibilité du code, Pascal (Delphi) bat les C les mains de la famille.

Ce n'est pas une étude formelle, mais il vaut la peine d'y penser.

Answer 3

Comparaisons quantitatives de ce type serait très difficile à cerner, en raison du nombre de complications variables: des développeurs d'expérience avec la langue, la pertinence de la langue vers le domaine cible, des développeurs de qualité globale (ça fait valoir que les principaux langages attirer plus de qualité développeurs), les compromis avec le produit résultant (c'est un Ruby ou Python application aussi rapide qu'un bien écrit en Delphi ou C++ application?), etc.

Dans le Code Complet, 2e Ed., Steve McConnell listes de plusieurs langues en fonction de leur puissance expressive (nombre de lignes de l'équivalent du code C peut être exprimé dans un état unique de chaque langue). Il a été suggéré que les programmeurs de la productivité dans les lignes de code est relativement constante quelle que soit la langue; si cela est vrai, alors la puissance expressive de chaque langue doit donner une estimation approximative du coût relatif de développement dans chaque langue. Le Tableau 4.1, page 62:

NIVEAU DE LANGUE PAR RAPPORT À C
C 1
C++ 2.5
Fortran 95 2
Java 2.5
Perl 6
Python 6
Smalltalk 6
Visual Basic 4.5

Il dresse la liste de plusieurs sources pour ce tableau: Estimation des Coûts de Logiciels, Logiciel Estimation des Coûts avec Cocomo II, et "Une Comparaison Empirique de Sept Langages de Programmation" (par Prechelt, de la IEEE Computer, octobre 2000).

Les chiffres que McConnell cites sont tous des vieux de plusieurs années, mais ce que je comprends, le Cocomo II modèle est incroyablement détaillé, de sorte actuel Cocomo II matériel peut offrir des chiffres actuels sur Delphi et C#.

Answer 4

Je n'ai jamais regardé pour une telle étude, mais je serais surpris si l'on existait. Toute expérience destinée à mesurer et à comparer les coûts de développement à travers plusieurs langues dans un bon scientifique de la mode serait extrêmement coûteux.

Pour le faire correctement:

• Vous devez spécifier un nombre non négligeable de projets dans un éventail de domaines d'application.

• Vous auriez besoin de former un certain nombre d'équipes de projet, dont chacun est composé de développeurs ayant une expérience significative dans le développement d'applications à grande échelle dans l'une des langues.

• Ensuite, vous devez mettre en œuvre chaque projet N fois pour chaque langue ... pour obtenir un résultat statistiquement significatif.

De sorte que vous devez développeur effort équivalent à project-size * nos-languages * nos-projects * nos-repetitions. En supposant un projet non trivial prend 1 homme de l'année, qu'il y a 5 projets et ils sont développés à 5 fois dans chaque langue (pour nous donner une assez grande taille de l'échantillon statistiquement significative), qui est de 25 ans d'expérience années de développement ... dire de US$2 millions à 5 millions de dollars ... PAR LANGUE ÉTUDIÉE.

Ces chiffres sont (évidemment) tiré de l'air, mais mon point est qu'un bon scientifique de comparaison des coûts de développement pour l'autre langue serait d'un coût prohibitif.

Et même alors, les résultats de l'étude ne serait pas à l'adresse:

• en cours de maintenabilité / coûts de maintenance,
• comment les chiffres à l'échelle de grands projets,
• la langue des effets spécifiques de la taille de l'équipe,
• la disponibilité, les coûts et les avantages des outils de développement pour les langues respectives,
• la facilité / difficulté de former des équipes expérimentées pour chaque langue,
• et ainsi de suite.

Et que les résultats pourraient être dépassées dans les 3 à 5 ans.

Answer 5

Peopleware (par Tom DeMarco et Timothy Lister) contient une section dans le chapitre huit, à propos de "Codage des Jeux de Guerre". De 1984 à 1986, plus de 600 développeurs ont participé.

Dans leur analyse des résultats du jeu, ils ont découvert que le langage de programmation n'avaient que peu ou pas de corrélation avec le rendement. (Seulement la langue de l'assembly participants ont eu mal à gauche derrière par tous les autres groupes de langues)