[josm-dev] Refactoring of the JOSM architecture vs. Plugins

[Frederik Ramm]

Hi,

>> true conviction that many things will actually be *harder* to do once 
>> they've done their work, not *easier* (especially for programmers who 
>> are not Java experts). 
> 
> Why do you think that this is the case?

Proper encapsulation often brings with it a kind of 
non-straightforwardness. The first example to come to my mind, but 
surely not the only one, is the usual concept of listeners and event 
sources. It's second nature to people using it on a daily basis, but 
quite difficult to follow for someone who doesn't. If you have a 
"window.repaint()" somewhere then everyone understands what this means, 
but if you fire an event which will be caught by whoever has registered 
as a listener then the casual viewer of the code has to find out who 
registers as a listener and when and what they'll do with the event.

I have had many unhappy encounters with over-engineered Java code where 
I had to dig through byzantine arrays of classes, most of which did 
nothing but delegate something to some other class - you were at A and 
wanted to pass a message to B, requiring you to change signatures on 
methods of C, D, and E just to pass through that extra bit of info, 
things like that. Now you'll say that that must have been bad design 
then, but take something like Swing which is surely designed by people 
who should know, and does work quite well, but it's a nightmare if you 
think you could just invest an hour and "scratch an itch" below the 
shiny surface.

I haven't seen code designed by any of those calling for wholesale 
refactoring because of the "yuck" factor. They could be reasonable 
programmers who know when to do something by the book and when it serves 
nothing but to demonstrate that they have read the book. They could also 
be people who can't deal with anything they have not written themselves. 
How would I know if they pile up demands about what has to be changed 
with JOSM before they even touch it?

> Refactoring is supposed to make code easier to understand for everyone,
> not easier to understand for code ninjas and harder to understand for
> the general population. Do you think that it's impossible to make JOSM's
> code easier to understand and work with for everyone?

I am sure it is possible to make JOSM's code easier to understand and 
work with for many, but I'm also sure that converting everything to use 
standard standard OO practices and design patterns will actually make it 
harder for people who want to contribute, and successfully have 
contributed in the past, unless they have prior Java exposure.

>> Will I, as the JOSM maintainer, be able to count 
>> on these people to actually do the important work (i.e. adding features, 
>> fixing bugs and so on) AFTER they have turned JOSM inside out - or will 
>> they just continue to find reasons why they cannot contribute to JOSM as 
>> it is, or (even worse) move on to refactor something else, thinking 
>> they've improved JOSM when in fact they have made life more difficult 
>> for the existing developers, all with the promise that it will surely be 
>> easier to attract new ones?
> 
> Why do you think refactoring will make your life more difficult?

The existing developers are used to working with the existing code. Is 
it not obvious to you that a major style change will require everyone to 
get used to the new way of doing things?

>> JOSM is currently designed in such a simple fashion that I can honestly 
>> ask someone who is only a C++ or Ruby or whatever programmer to 
>> implement features. 
> 
> Genuine question: how often does this happen?

JOSM doesn't have a lot of developers, but I have already mentioned Dirk 
who says of himself that the last time he programmed Java was many years 
ago, and I believe you have read David Earl's posting earlier in this 
thread. There are about three or four other people working on JOSM with 
varying intensity and that's it.

> What makes you think that best practice in other OO languages (with
> which these people will hopefully be familiar)

I think if we'd make it a requirement that people should "hopefully be 
familiar with best practice in other OO languages" then we'd lose half 
of JOSM contributors.

Is it possible that you are seeing JOSM primarily as a programming 
project, one in which programmers invest their time because they like 
programming? Because in my eyes it isn't.

> How about one person like Dirk and twenty people all contributing
> because the design has been cleaned up?

That would be ideal but I doubt it. Or at least I see a very big danger 
of going over board in refactoring. At least Dirk seems to have had no 
problems in dealing with JOSM as it was when he joined (search for 
subject "JOSM code quality").

> Who has suggested that this is their plan, or given any indication that
> this might be what they are up to?

We have had a number of people who showed up on the mailing list, their 
first post being something along the lines that everything needs to be 
refactored and they're willing to help. Then you tell them to take it 
slow, and then they're gone. I'm sorry but I cannot believe that these 
people actually care for OSM and want to help improving life for the 
mappers. Get involved, take a share of the responsibility, and then work 
with the others to get things done, that's the way it would work. But 
coming into the room wielding your Best OO Pracices book and telling 
everyone how crappy everything is (and by the way you're willing to 
relieve them of their misery and share some enlightenment) is just not 
the way to achieve success. With behaviour like this you'll hit a brick 
wall everywhere.

(Recent example: Torvalds talking about people who show up and the first 
thing they do is submit a giant patch to the Linux kernel:
http://news.zdnet.co.uk/software/0,1000000121,39462454,00.htm?r=9)

I'm getting tired of this conversation and I believe everyone else is, 
too. I'm doing what I do because I think it is best for JOSM and its 
users. I'm not claiming a monopoly here. Go contribute to JOSM-NG (or, 
by the way, Merkaartor which reportedly is also well-written). Go check 
out JOSM and build a replacement if you can't be bothered to help 
JOSM-NG. Or help improving JOSM, slowly.

I found Joerg's idea of heading in the MVC direction for the map 
display, and having a good spatial index to support fast drawing, quite 
good and I also think this is something where we could attempt a small 
scale refactoring, limited to what is actually needed to reach that 
goal. Joerg is at least someone who has taken the effort to work with 
the existing code and knows whereof he speaks. (I have already written 
that you don't even need accessors to implement a spatial index but if 
Joerg's willing to do the work then it's probably fair to let him decide 
how he does it... as is custom elsewhere in OSM.)

Maybe the whole discussion is also blown out of proportion by the fact 
that we haven't really defined what refactoring means. If I were to toy 
with optimizing the drawing routines and I wound that I can triple 
drawing speed if I introduce better encapsulation for some of the 
properties, I would probably just do it without saying that I 
"refactored" the code. When I hear "refactoring" I always think of 
someone using his Eclipse or whatever to encapsulate every single public 
variable even if he doesn't have a clue what it is used for, instead of 
doing focused work aimed at reaching a goal.

Bye
Frederik

-- 
Frederik Ramm  ##  eMail frederik at remote.org  ##  N49°00'09" E008°23'33"