Studies of relative development costs in different languages

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

+58
java c # delphi
May 30 '10 at 19:54
source share
8 answers

Quantitative comparisons of this kind would be very difficult to fix due to the number of complicating variables: the experience of developers with the language, the suitability of the language for the target domain, the overall quality of the developers (it was argued that non-mainstream languages ​​attract higher-quality developers), trade-offs with the resulting product (is this a Ruby or Python application as fast as a well-written Delphi or C ++ application?) etc.

In Code Complete, 2nd Ed. , Steve McConnell lists several languages ​​in terms of their expressiveness (how many lines of equivalent C code can be expressed in one expression of each language). It has been suggested that programmer productivity in lines of code is relatively constant regardless of language; if so, 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: Software Cost Estimation , Software Cost Estimation Using Cocomo II, and "An Empirical Comparison of Seven Programming Languages" (from Prechelt, from IEEE Computer , October 2000).

The numbers McConnell quotes are only a few years old, but from what I understand, the Cocomo II model is ridiculously detailed, so the current Cocomo II stuff can offer current numbers in Delphi and C #.

+13
May 30 '10 at 21:44
source share

No. But I'm not a fanatic, and I work as a consultant and use to recommend one of them for each of my requirements. So, here are some facts to make it easier to choose what to use to meet the system design requirements you may have.

Generally:

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 option for the development of the nation.

All of them have:

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

All of them:

  • Highly reliable technology with RAD capabilities.
  • The best development support tools are supported (UML, etc.).
  • Releasing major updates to their technologies (Java 7, .NET 4.0 and the multi-platform Delphi platform).

Differences:

3 Things Better In C #:

  • The number of available developers (compared to Java) that can encode in it (*).
  • Microsoft is behind.
  • Cheaper development costs in terms of wages (usually).

3 Things Java is Better In:

  • The number of available developers (compared to Delphi) that can encode in it (*).
  • Portability.
  • The sun is falling behind.

3 Things Delphi Is Better In:

  • Speed ​​(higher performance for mission-critical systems).
  • Small footprint (the Delphi compiler generates really small binaries).
  • It has no explicit dependencies (simpler distribution).



(*) There is a very reliable fact that there are other developer languages ​​that can program in C # than developers of other languages ​​that can code in Java, which means that it is easier to find programmers in C #. Perhaps this explains why on many websites (like this one) and on forums that resolve multilingual questions, refactoring, etc., there are MORE more questions and answers in C # ( 84k vs 50k ). In addition, since Java jobs are best paid in many parts of the world, common sense indicates that Java developers stay longer in their jobs than in C #, making it difficult to find Java developers available for C #. And, of course, there are some other factors that can be discussed, but I'm sure it is usually easier to find a C # programmer than Java.

+36
May 30 '10 at 21:22
source share

I don’t know about formal research, but I heard a lot of anecdotal reports that companies accept an existing application in Delphi and rewrite it in C # for one reason or another. They all end in much the same way.

it took twice as long to rewrite the program in C #, as was done to initially write it to Delphi, even with all the business logic and domain knowledge already developed and presented as an existing Delphi code base. During this time, they did not release updates because all of their resources were busy with rewriting, which allowed their competition to gain market share. And when it was done, it was a product at level 1.0. Glitchy is slow and hard to use, often with serious backward compatibility issues.

The reason for being open to interpretation, but I believe that one of the main factors that make Delphi much more productive than C # (or Java) is appearance and language.

It is well known that much more work, time and effort goes into maintaining and debugging modern programs than initially discussing them, but this principle is not always brought to its logical conclusion. If what requires the most work is the support of the program, then choosing a language based on its simple or quick code writing is a premature optimization. You get the best 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) is superior to C-shaped transmission.

This is not a formal study, but worth considering.

+32
May 30 '10 at 11:50 a.m.
source share

I never looked for such a study, but I would be surprised if I existed. Any experiment designed to measure and compare actual development costs in multiple languages ​​from a scientific point of view will be incredibly expensive.

To do it right:

  • You will need to specify several non-trivial projects in different application domains.

  • You will need to form a number of project teams, each of which consists of developers who have significant experience in developing large-scale applications in one of the languages.

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

So, you need a developer power equivalent to project-size * nos-languages * nos-projects * nos-repetitions . Assuming that a non-trivial project takes 1 person-year, 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), i.e. 25 years of development experience ... let's say from 2 to 5 million US dollars ... IN THE LANGUAGE RESEARCHED.

These figures are (obviously) taken off the air, but I believe that a proper scientific comparison of development costs for different languages ​​would be prohibitively expensive.

And even then, the results of the study will not concern:

  • ongoing support / maintenance costs,
  • as a scale of numbers for large projects,
  • language features of team size,
  • Availability, costs and benefits of development tools for their respective languages,
  • ease / complexity of forming experienced teams for each language,
  • etc.

And the results will be obsolete in 3-5 years.

+6
May 31 '10 at 12:26 a.m.
source share

Peopleware (from Tom DeMarco and Timothy Lister) contains a section in Chapter 8, "Encoding War Games." From 1984 to 1986, more than 600 developers participated.

In their analysis of the results of the game, they found that the programming language has little or no correlation with performance. (Only members of the assembler language were hit hard by all other language groups)

+4
Dec 01 '10 at 20:33
source share

The U.S. Air Force became interested and found that Delphi would code much faster. The C ++ competition every year attracts speed coding teams to competitions. Delphi encoders hide this competition and almost always come much faster with the required code.

After my career as head of the Air Force’s engineering department, my former boss, Bill Retzheim, wrote a book on estimating software development costs. His choice, head and shoulders above all others are Delphi. It was version 3/4. Rational used his assessment template. I still use it, and nothing better has appeared in all the years that I have been doing.

Clarity of design and power of expression in the code does not change much compared to versions. Most of the time you look at visual changes and incremental increase. Key practical recommendations 20 years ago are still being applied. That is what makes architecture possible. We know what the best methods look like, because at a certain scale, the code must comply with a certain set of standard requirements, which do not differ much. You can almost always make it more enjoyable to use or have less silly awkward interfaces, but the data, security / filtering and workflow systems that make business systems work still use the same design patterns from GoF Design Patterns. And if small devices have taught us something, then it should be noted high clarity and simplicity. It is important for the whole group how easy it is to use your code base for this purpose. All major environments can work very well with domain design. System speed and ease of development make Delphi and Node.js my two back preferences. But smart C # and Java are both good. If I were concerned about the security of the development environment, I would go to C # in some situations, because it was difficult for developers to break the rules. But when I do not need these rules, that is, most of the time, I prefer a more open environment that scales. When I don't really care about security, I might prefer Node.js because it is done in a hurry. Most of the time I find it is too easy to make a mistake in Node, and in the end I need full coverage of the test code. Delphi is my first choice on balance.

+3
Jan 26 '14 at 20:21
source share

"developer quality" is hard to evaluate. Java and (to a lesser extent) C # are used a lot in schools and universities to educate students in the rudiments of programming. Many of them find themselves in support forums with questions about homework and will be considered somehow to be programmers (and poor) using this language. In fact, the vast majority of them will never write one line of code after completing this required introductory course, and most of the rest probably will not write in this language.

--- talk about the "comparative studies" about the full competence of the programmer ---

As said, it is very difficult, if not impossible, to estimate the cost of comparison for implementing something in different languages, at least as a general case that will be used for all projects. Some things give .NET better, others Java, others are best done with Excel macros.

And the development cost usually makes up only a small part of the total cost of ownership of the system, especially if it is something like a multi-level application running on application servers with databases, etc. If the client already has a server server working with IIS with MS SQL Server databases as a backend, selling them Java EE applications using the Oracle backend makes them bad, even if this would be the most logical choice for the application otherwise. The development cost may be lower, but the current cost for the client will be much higher.

At the other end of the scale, a website for your grocery store that wants to start accepting orders over the network for delivery in the neighborhood should not be implemented in either .NET or Java EE. The cost of the solution (especially hosting) far outweighs the benefits. A simple thing, based on, for example, php or rails, will serve this client much better. The cost of hosting is reduced, you do not need to pay expensive license fees for databases and application servers, he could make some money using the resulting website.

+2
May 31 '10 at 13:12
source share

Like others, there is no research ... because no one is interested. There is no noticeable difference. Take almost any project management book, and you will not see references to languages ​​prohibiting examples without relying on specific language features. In most cases, any problems with the consumption of money in the project life cycle are not coding problems, but architectural and organizational.

To look at things in perspective, if you encounter a serious lack of language and need to implement some workaround, you lose a few hours. Maintaining a person could spend a few more hours understanding what and why you did there. A working day or two will be lost. Well, if you come to work in the wrong mood, you lose that day. If you have problems understanding the requirements or communicating with colleagues and management, you easily lose weeks and months.

0
May 31 '10 at 6:46 a.m.
source share



All Articles