Some of that regarding navigation is simply use of their IDE. There are a lot of Eclipse users out there who don't know about Navigate -> Go To -> Type (Ctrl-Shift-T by default I think), and instead navigate through the Project Explorer or keep an insane number of files open.
And even when you show them they think it's black magic and continue to do it their way. Eclipse's find usages is terribly slow, even on private members (wtf?). It's truly the tool of choice for those unaware that they have a choice. IntelliJ IDEA's often doesn't get time to bring up a progress bar. IDEA also has a 'Analyse data flow from.." and "Analyse data flow to.." which can be astonishingly useful, though I must admit not using them as much as I expected to when I first discovered them. To give some perspective, I can often fix problems by doing a Ctrl-Shift-F to search all files for an error message or user interface string, then (even if it's a UI string in a .properties file) use Alt-F7 to find all uses, make some edit and retest, without ever really having any knowledge of what files I'm editing, and without ever having to watch a progress bar for more than a couple of seconds at a time. As long as Eclipse takes longer to do something automatically than the user does manually it will always be a distracting environment, and will encourage the kind of practice you mention. On Mon, Jun 13, 2011 at 6:23 PM, Fabrizio Giudici <[email protected]> wrote: > 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 > [email protected] > > -- > You received this message because you are subscribed to the Google Groups > "The Java Posse" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]. > For more options, visit this group at > http://groups.google.com/group/javaposse?hl=en. > > -- You received this message because you are subscribed to the Google Groups "The Java Posse" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.
