0

I'm trying to determine if a language I'm investigating (Groovy) is better for developing enterprise applications than our current language (Java). Specifically I'm trying to figure out if it will save significant time in coding, re-factoring and maintenance.

But, I'm not actually asking that question here as it's waaaaay too broad, I'm just setting up my actual question:

What's the best approach to gathering metrics to compare the productivity of two languages? I mean, it's easy to look at example code that says "see, this is easier to write in Groovy than Java" or "this functionality is missing in the tools available for Groovy, but exists with Java tools." But it's much harder to figure out how that translates into time gained/lost in the real world.

I've been combing Google, but I'm honestly not even sure what I'm looking for. I know the question is still a tad broad, but if anyone has some answers I would appreciate it...

Jay Carr
  • 231
  • 1
  • 8
  • 1
    possible duplicate of [How do you choose to use a specific programming language?](http://programmers.stackexchange.com/questions/65047/how-do-you-choose-to-use-a-specific-programming-language) See also: [Are there any empirical studies on the effect of different languages on software quality?](http://programmers.stackexchange.com/questions/98669/are-there-any-empirical-studies-on-the-effect-of-different-languages-on-software) – gnat Sep 16 '14 at 15:22
  • In short, there are few studies, and arguably no good studies, since it's pretty much impossible to isolate the test environment to _just_ the programming languages (and their environments). The programmers' skill and experience play a huge role, as does the variety of problems needed to be solved by general purpose programming languages. – Telastyn Sep 16 '14 at 15:25
  • It's good to look beyond whether something's "easier to write in Groovy" and whether the functionality exists in Groovy, and instead look at "time gained/lost in the real world". But don't forget other real-world metrics such as costs and risks. By risk I mean as an example that the static compilation of Java was written and tested by hundreds of people over a decade or two, whereas the static compilation of Groovy 2 was written by a single lone programmer a mere two years ago. – Vorg van Geir Sep 21 '14 at 11:28

2 Answers2

2

Write a small, but non-trivial application in the candidate language, and make a qualitative evaluation of the learning curve, ease of development, relative friction of the tool chain, and developer productivity.

Robert Harvey
  • 198,589
  • 55
  • 464
  • 673
1

I'd set up an experiment:

  1. Find a bunch of interns with strictly Microsoft experience. Train them on your Java tools and the language then give them a small project.
  2. Find some more interns (same number) also with strictly Microsoft experience. Train them on the Groovy tools and language then give them the same small project.

You want as many interns as possible but equal numbers on both teams. 'Strictly Microsoft experience' is so everyone is starting from roughly the same background (no head starts in Java or Groovy).

Try to pick "average" interns - not superstars that will skew the results or people you already know you won't try to hire when they graduate. If you have enough of them you can hopefully average out their skill and experience levels.

All of the interns get a great learning experience, and you get the benefit of seeing how they tackle the projects and how steep the learning curve is. The internship experience can be an excellent way to find great new hires, and what better test than to give them an unfamiliar language and a solvable but nontrivial problem?

There should be an item #3 in the list above as a control, but I'm not sure what it is.

Dan Pichelman
  • 13,773
  • 8
  • 42
  • 73
  • I don't understand the "strictly microsoft experience". Why is that important? – iveqy Sep 16 '14 at 15:53
  • @iveqy - I think that's so that neither group has any Java or Groovy experience, thus giving us a clean slate to work with. – Jay Carr Sep 16 '14 at 16:04
  • @JayCarr maybe so. But I don't think you should say "no java or groovy experience" == "only Microsoft experience". That's not the same. – iveqy Sep 17 '14 at 15:44
  • Not necessarily, but if we're looking for examples of having "no java or groovy experience" then someone who has "strictly Microsoft experience" would fit. Assuming, of course, that the original poster meant "just .NET experience" (which I think he did). But yes, I'd agree that it's not the only example out there. – Jay Carr Sep 17 '14 at 15:49
  • @iveqy - Jay is correct - I just wanted relatively new developers with some other development experience but not Groovy or Java. "Strictly Microsoft" seemed a cheap and easy to find specification. – Dan Pichelman Sep 17 '14 at 16:00