In response to Mario's point about the ROI of Scala, let me tell you a
short anecdotal story which expresses well my point. It's not about
Scala, but about people's _perception_ of what's effective, efficient,
easy and intuitive (E3I from now on).
The past week I've run an exercise together with a customer, where we
designed a prototype of a webapp. The main purpose was to reduce the
evaluation uncertainty about the feasibility of some parts, in
particular the integration with an existing back end, and the
uncertainty about what should be really done. In fact, they asked for an
estimate of the costs for the whole app and I always refuse to make an
estimate without spending a few days to build a prototype. At the same
time, I took the chance to introduce a number of things into the
prototype, from design practices, to a deeper use of some technologies
such as Spring - that the customer only used at a minimum level - to the
introduction of Maven. Extreme satisfaction of the customer (and mine,
as I had fun and was even get paid for that).
For sure in this mailing list there will hardly be two persons with the
same opinion on my design decisions ;-) but I think that everybody gives
thumb up on a point: the app is made by several tiny classes, averaging
10-20 LoC each, Single Responsibility Principle applied to full extent,
everything interchangeable and injected; tell don't ask and domain
classes without getter. Perhaps everybody agrees on the goodness of
these points.
The customer's code is usually made of very long classes, 500+ LoC and
some more than one thousand. He was already aware that this is evil, but
needed some exercising to understand how to get to a design process with
better metrics. He liked what was produced in this week.
Still, the guy has got doubts that this style of design can be applied
to his developers. When I introduce the many-small-classes to people
who's accustomed to less-fat-classes, for instance, I note that they
have troubles to navigate the tree (for instance, to pick the proper
class where to make a change). The solution is, of course, to be picky
and consistent with name schemes. In turn, this requires training - and
there's a personal attitude thing, for which some people will find it
natural at a certain point, others not. I've seen code where people
didn't refactor the method names when, slowly, they started to do things
that were different to the initial one - and this operation only
requires a ^R. So: that good design, in abstract, is more effective than
a design with longer classes. It's even easier for me, but not for my
customer, at least now. And since he doesn't feel at ease with it, at
the moment, he won't be more efficient with it.
I call this "karma" levels. A given karma, to my definition, is a set of
practices that you are acquainted to and you can master. A karma level
n-1 is made by practices that we can agree are better than ones at karma
n; but people used to karma n would find it difficult to work at karma
n-1. For instance, karma 5 could be use getters and setters (JavaBeans,
JPA, etc..). Karma 4 could be not to use them. You can't abruptly bring
people used to karma 5 to karma 4: they will panic. You can do with the
proper pace and training. I think that not all people can work at higher
karma levels. After all, everybody can learn to drive a small utility
car, not everybody is able to drive a F1 car.
So, you could convince me that Scala is at a higher karma than Java. We
of course agree that a number of people could be taught to work at a
higher karma - but this would require training. You might disagree, but
I don't think some people will find ever at ease at higher levels.
Consider also the motivational aspect: not everybody is passionate about
his work. I know people that code just for a living and leave at 8 hour
of work o' clock. They are marginally interested in working better,
especially considering that they feel they aren't below the average and
that, in a war or another, they get the job done.
In this scenario, how can I have a ROI with Scala?
--
Fabrizio Giudici - Java Architect, Project Manager
Tidalwave s.a.s. - "We make Java work. Everywhere."
java.net/blog/fabriziogiudici - www.tidalwave.it/people
fabrizio.giud...@tidalwave.it
--
You received this message because you are subscribed to the Google Groups "The Java
Posse" group.
To post to this group, send email to javaposse@googlegroups.com.
To unsubscribe from this group, send email to
javaposse+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/javaposse?hl=en.
