Studies of relative costs for development in different languages

Question

Has anyone seen a recent (and fairly balanced) study into the relative costs for software development using differing languages ? I would particular like to see the relative costs of Java Vs. C# Vs. Delphi.

Answer 1

No. But I'm not fanatic of any, and work as consultant and use to recommend one of them for every requirement I have. So here are some facts to make easier the choose of what to use to address system development requirements that you can have.

In Common:

All of them are the best in their fields:

• Java is the best Java development option.
• C# is the best .NET development option.
• Delphi is the best Native development option.

All of them have:

• Worldwide third party vendors that provide quality components and libraries.
• Worldwide well-known applications created with them (for example the Delphi ones may be are more known: Yahoo Go for TV!, Macromedia Captivate, TotalCommander, MediaMonkey, FinalBuilder, InstallAware, WinLicense, MySQL Administrator, etc).

All of them are:

• Highly reliable technologies with RAD capabilities.
• Supported by the best development aid tools (UML, etc).
• Releasing major upgrades in its technologies (Java 7, .NET 4.0 and Delphi multiplatform).

Differences:

3 Things in which C# is better:

• Quantity of developers available (comparing with Java) that can code in it (*).
• Has Microsoft behind.
• Cheaper development costs in terms of wages (usually).

3 Things in which Java is better:

• Quantity of developers available (comparing with Delphi) that can code in it (*).
• Portability.
• Has Sun behind.

3 Things in which Delphi is better:

• Speed (better performance for time critical systems).
• Small footprint (the Delphi compiler generates really small binaries).
• Has no explicit dependencies (easier distribution).

---

(*) there is a very reliable fact that there are more other-languages-developers that can code in C# than other-languages-developers that can code in Java, that means its easier to find C# programmers. Maybe that explains why in many websites (like this one) and forums that allow multi-language questions, refactorings, etc, there are USUALLY more C# questions and answers (84k vs 50k). Also, since Java jobs are best paid in many parts of the world, common sense points out that Java developers remain longer in their jobs than C# ones, that makes more difficult to find Java developers available than C# ones. And of course there are some other factors that can be discussed, but I'm pretty sure it's usually easier to find a C# programmer than a Java one.

Answer 2

I don't know about formal studies, but I've heard plenty of anecdotal accounts of companies taking an existing app in Delphi and rewriting it in C# for one reason or another. They all end about the same way.

It took twice as long to rewrite the program in C# as it did to originally write it in Delphi, even with all the business logic and domain knowledge already worked out and present in the form of the existing Delphi codebase. During this time, they were not releasing updates because all their resources were busy with the rewrite, allowing their competition to gain market share. And when it was done, it was a 1.0-level product. Glitchy, slow, and hard to use, often with severe backwards-compatibility issues.

The reason why are open to interpretation, but I think one of the major factors that makes Delphi so much more productive than C# (or Java) is the language's look and feel.

It's common knowledge that a lot more work, time and effort goes into maintaining and debugging modern programs than initially wriitng them, but That principle isn't often followed to its logical conclusion. If what requires the most work is maintaining the program, then picking a language on the basis of it being easy or quick to write code in is premature optimization. You get a better return on your investment if you use a language that is easy to read and maintain. And when it comes to code readability, Pascal (Delphi) beats the C family hands-down.

It's not a formal study, but it's worth thinking about.

Answer 3

Quantitative comparisons of this sort would be very hard to pin down, due to the number of complicating variables: developers' experience with the language, suitability of the language to the target domain, developers' overall quality (it's been argued that non-mainstream languages attract higher quality developers), tradeoffs with the resulting product (is a Ruby or Python app as fast as a well-written Delphi or C++ app?), etc.

In Code Complete, 2nd Ed., Steve McConnell lists several languages in terms of their expressive power (how many lines of equivalent C code can be expressed in a single statement of each language). It's been suggested that programmers' productivity in lines of code is relatively constant regardless of language; if this is true, then the expressive power of each language should give a rough estimate of the relative cost of development in each language. From Table 4.1, page 62:

LANGUAGE       LEVEL RELATIVE TO C
C              1
C++            2.5
Fortran 95     2
Java           2.5
Perl           6
Python         6
Smalltalk      6
Visual Basic   4.5

He lists several sources for this table: Estimating Software Costs, Software Cost Estimation with Cocomo II, and "An Empirical Comparison of Seven Programming Languages" (by Prechelt, from IEEE Computer, October 2000).

The figures that McConnell cites are all several years old, but from what I understand, the Cocomo II model is ridiculously detailed, so current Cocomo II material may offer current numbers on Delphi and C#.

Answer 4

I've never looked for such a study, but I would be surprised if one existed. Any experiment designed to measure and compare actual development costs across multiple languages in a proper scientific fashion would be incredibly expensive.

To do it properly:

• You would need to specify a number of non-trivial projects across a range of application domains.

• You would need to form a number project teams, each of which is composed of developers with significant experience in developing large-scale applications in one of the languages.

• Then you would need to implement each project N times for each language ... to get a statistically significant result.

So you would need developer effort equivalent to project-size * nos-languages * nos-projects * nos-repetitions. Assuming a non-trivial project takes 1 man-year, that there are 5 projects and they are developed 5 times in each language (to give us a large enough sample size to be statistically significant), that is 25 experienced-developer-years ... say US$2 million to US$5 million ... PER LANGUAGE EXAMINED.

Those numbers are (obviously) pulled out of the air, but my point is that a proper scientific comparison of development costs for different language would be prohibitively expensive.

And even then, the study results would not address:

• on-going maintainability / maintenance costs,
• how the numbers scale to large projects,
• language specific effects of team size,
• availability, costs and benefits of development tools for respective languages,
• ease / difficulty of forming experienced teams for each language,
• and so on.

And the results would be out-dated in 3 to 5 years.

Answer 5

The US Air Force was interested and found Delphi to be significantly faster to code in. The C++ competition every year attracts speed coding teams to a competition. Delphi coders shadow this competition and almost always come in significantly faster with the required code.

After his career as head of Air Force development my former boss, Bill Roetzheim wrote the book on estimating software development costs. His choice, head and shoulders above all others was Delphi. That was version 3/4. Rational used his estimating pattern. I still use it, and nothing better has been forthcoming in all the years I have been doing it.

Clarity of design and the power of expression in code doesnt change much over versions. Most of the time you are looking at visual changes, and incremental augmentation. The core best practices from 20 years ago still apply. That is what makes Architecture possible. We know what best practices look like because at a certain scale the code has to conform to a certain set of standard requirements that dont vary much. You can almost always make it nicer to use, or have fewer stupid awkward interfaces, but data, security/filtering, and workflow systems that make business systems work still use the same design patterns from the GoF Design Patterns book. And if small devices have taught us anything, it is that intense clarity and simplicity is to be commended. It matters a whole bunch how easy your code base is to use for the purpose. All major environments can do domain design pretty well. The speed of the system and ease of development make Delphi and Node.js my two back end preferences. But capability wise C# and Java are both fine. If I was concerned about security of the environment against developers I would go for C# in some situations because it is harder for coders to violate the rules. But when I dont need those rules, ie most of the time, I prefer a more open environment that scales. When I dont much care about security I might prefer Node.js because it gets it done in a hurry. Most of the time I find it too easy to make mistakes in Node and I need full test code coverage eventually. Delphi is my first choice on balance.

Answer 6

Peopleware (by Tom DeMarco and Timothy Lister) contains a section in chapter eight about "Coding War Games". From 1984 to 1986, more than 600 developers have participated.

In their analysis of the game results, they discovered that the programming language had little or no correlation to performance. (Only the assembly language participants got badly left behind by all the other language groups)

Answer 7

"quality of developers" is hard to gauge. Java and (to a lesser extent) C# are used a lot in schools and universities to train pupils in the rudiments of programming. Many of these end up on support forums with homework questions and would be counted somehow as being programmers (and poor ones) using that language. In reality the vast majority of them never will write a single line of code after completing that mandatory introductory course, and most of the rest probably won't write in that language.

--- rant about "comparative studies" about programmer competence complete ---

As said, it's very hard if not impossible to give a cost comparison estimate for implementing something in different languages, at least as a general case to be used for all projects. Some things lend themselves better to .NET, others to Java, others again might be best done in Excel macros.

And development cost is usually only a fraction of the TCO of a system, especially if it's something like a multitier application running on application servers with databases, etc. If the customer already has a serverfarm running IIS with MS SQL Server databases as a backend, selling them a Java EE application using an Oracle backend is doing them a disservice, even if that would be the most logical choice for the application otherwise. The development cost might be lower, but the running cost for the customer would be a lot higher.

On the other end of the scale, a website for your corner grocery store who wants to start taking orders through the net for delivery in the neighbourhood shouldn't be implemented in either .NET or Java EE. The cost of the solution (especially hosting) would far outweigh the benefits. A simple thing based on for example php or rails would serve that customer far better. Hosting cost is reduced, no expensive license fees for database and application servers needs be paid, he might actually make some money using the resulting website.

Answer 8

Like others said, there is no studies... because nobody is interested. There is no measurable difference. Take almost any book on project management and you'll see no mention of languages barring examples, no relying on specific language features. Most time any money consuming problems over project life cycle are not coding problems, but architectural and organizational.

To put things in perspective, if you encounter serious drawback of the language and have to implement some workaround - you lose a few hours. Maintaining person might spent some more hours understanding what and why you did there A work day or two will be lost. Well, if you come to work in a wrong mood, you lose the same day. If you have problems understanding requirement or communicating with colleagues and management, you easily lose weeks and months.