Elliotte Rusty Harold says, "I think implementing all those examples helped clarify a lot of the thoughts I had about what was worth putting in the API and what wasn't. In some cases it proved I needed new things. In other cases it proved I could afford to take certain things out."

Read this Artima.com interview with Elliotte Rusty Harold:

http://www.artima.com/intv/desbyuse.html

What do you think of Rusty's comments?

About running non-compiling test cases: Eclipse does it very well..

It is able to run test cases even if some of the files only partially compile... For the methods that didn't compile, it will just substitute a throw new Error("Unresolved compilation error"), so when running the test suite/case it will just cause a red bar, but proceed with the rest...

I've spent ages trying to formulate my response to this after working in an environment which featured a dictator and ended introducing some considerable flaws into the object model and API... that experience was so terrifying that I find myself getting angsty at the mere thought of going down such a route.

Ultimately I would simply say that many eyeballs results in fewer bugs... a paraphrase for sure, but still the most important thing you could ever learn.

Design by committee is not fun and can lead to conflicts... but it at least considers the views and experience of more people. This can only help the design process consider more possibilities and step closer to a consensus that isn't based on the thoughts and opinion of an individual, but the experiences and agreement of a group.

I hope that I never forget this lesson... it was learnt the hard way. And when I find myself now, in a position where I could dictate if I chose to... it's comforting to me to see that I do not chose and favour the team/group/community perspective more highly.

We all have a lot to learn and none of us should presume that we know so much that we can dictate anything to anyone.

Apologies if this comes across as a flame... it's not supposed to be one... just passionate about the way in which I work... and that usually is as part of a 'we'.

> I've spent ages trying to formulate my response to this
> after working in an environment which featured a dictator
> and ended introducing some considerable flaws into the
> object model and API... that experience was so terrifying
> that I find myself getting angsty at the mere thought of
> going down such a route.

I suspect the difference in your case was that you had a dictator who told a team what to do, whereas Elliote is doing all the work himself, including using the API.

I've been in situations where someone went off and designed APIs and then expected everyone to use them, and it didn't work. But the main reason it didn't work is because the dictator wasn't going to be the one who had to live with the flaws - he wasn't doing the nuts-and-bolts work.

In a team environment you need to have some sort of concesus on the design because everyone has to live with it. In the XOM case, no one has to live with it except Elliote. Everyone else is free to use JDOM if they prefer, and the market will decided whether his vision is better.

> We all have a lot to learn and none of us should presume
> that we know so much that we can dictate anything to
> anyone.
>

I think Rusty is comparing having a single decision maker versus a more political decision process, like formal voting, for design decisions. Both approches can come up with good and bad designs. I think in the end it comes down to leadership. But I do agree with Rusty that having a single final decision maker can result in the best designs, so long as that decision maker is a good listener and has good design taste.

Dictatorship doesn't necessarily mean the leader doesn't listen to anyone. I ended up being the benevolent dictator for the ServiceUI API, but the design process involved many people in the Jini Community. I saw my role as pulling ideas from the community, sheparding the design forward, and picking and chosing when there wasn't consensus. In the Python community, Guido van Rossum gets a huge amount of community input, but ultimately he makes the final decision about what goes into Python. Anders Hejlsberg also said he played a similar role in the C# design team.

As with plain old governments, the risk with benevolent design dictatorships is that word benevolent. But if you are lucky enough get a good leader, you can end up with a nice, clean design.

> That's not what the test-driven development folks would
> say. They believe writing tests first in tiny iterations
> helps them discover a clean design.

Sure, but that assumes a context of building a concrete application and not a library in isolation. What I read Elliotte rediscovering is related to the principle of writing concrete applications and extracting a library or framework instead of creating a library from an abstract design.

> In IntelliJ IDEA, it's practically impossible to get
> anything done until your code at least compiles

I think that's intentional and I like that. I'm not sure I understand what "done" means for stuff that doesn't compile. The IDEA and now also the Eclipse approach is to write tests and call objects as if they already exist and use the intentional programming/quick fix features to rapidly create what you actually need.

As for design by benevolent dictatorship... My gut feel is that the issue is more about the criteria for whether design decisions are considered good over whether one or more people decide on it. I'm thinking the key is to argue designs using real working code (not just toy examples). Dunno. I'd prefer to have a live pair.