I run across this post, which I found interesting:

If someone give me a set of classes that doesn't bring a A to Z solution to a problem, sorry but I don't call it a Framework ... I call it a Base Class Library. I've been very supportive to the Entity Framework Team (I gave design feedback through multiple channels) but now I think I'm done.

This resonate very well with what Udi Dahan has said as a comment to Frans' post.

Microsoft is a platform company.

They build technologies that partners can build stuff on top of.

It's what they've always done.

It's what they're continuing to do.

Unfortunately, many developers in the Microsoft community don't know/understand this, thinking that these technologies are supposed to be used to build applications directly. This often causes overly complex codebases.

The EF's team's decision is consistent with providing a platform for partners to build their own ORMs on.

That being said, I don't care very much for a platform - just as I wouldn't drive the chassis of a car.

If I knew the answer, I would bottle it and would be rich. (insert mad laugher)

Lacking a bullet proof answer, the following are my observations regarding this issue. A while ago I was the chief interviewer in my company, and I have had the chance to interview literally hundreds of people. My own conclusions match Joel from 2005. The good people are already employed elsewhere, and are likely to be happy there. If they aren't happy, they tend to have the connections to find a job based on their known skills and experience.

In other words, unless something like the bubble burst has happened, you aren't going to find the good people in your interviews. This means that you have to look elsewhere for that.

I know that this isn't widely applicable, but I am using this blog as a good way of finding good people. The audience who reads this blog is already highly self selecting, and likely to share the same conceptions as I do about many things. I had several client engagements that resulted from this blog, and the environment I was working with was significantly higher than the industry average.

From the other side, the one thing that I am absolutely against is the "get a new job, close the blog" mentality. I wanted to point out couple of friends who did that, but I just checked, and both of them are blogging, which I somehow missed :-(

Anyway, what I am trying to say is that online presence matters. I have several friends who never had a blog, and wouldn't consider opening one. The direct implication is that some of the smartest people I have worked with are only known through word of mouth. Real story, I was at a client site one, and was half way listening to a hallway conversation, waiting for a conference call, and I heard the following: "Did you hear how Muhammad* saved [big cellular provider]'s when their [not important now]".

Some people has taken my suggestion to heart, and opened a blog. It doesn't really matter what they are talking about, what is important is that they do. Creating interactions in the community, creating a name for themselves. Getting recognized. Reputation matter, and having access to someone's thought stream over time is incredibly valuable in trying to estimate their abilities.

In the end, however, there is really no substitute for working with someone to actually evaluate their skills (which is a transient thing) and their abilities (which tend to change far more slowly, and what I really care about). Any attempt to short circuit the process is going to end in tears.

* That is his real name, and I had the pleasure of having him as my boss for over two years. Sadly, he doesn't have a blog. And yes, this is my own gentle way of trying to get him one.

The answer is a sound yes, but for a given value of success.

A bad team can still get a product out, and that product may even be successful. But the cost that this requires is far greater than it would have been otherwise, often to the point where you have no choice but to scrap the project. The really sad part is that some people accept this cost as the true cost of building software.

Oh, and good people doesn't necessarily equate to experts.

You need a few good people, but the rest of the team can follow fairly simple check list approach to development. There are a lot of stories about teams like that, and most of them end with a big project failure. Usually, this is because there was a hard separation between the people the business consider as the high end and the regular developers. This usually cause the people who actually dictate the architecture and shape of the system to become totally oblivious of any design issues that they may inflict on the rest of the team.

Having a mixed team, with the architecture and the implementation done by the same group, is a much better proposition in the long term. Note, however, that I am explicitly not saying that the whole team should take part in the design. This is an ideal circumstance, and I haven't found it to be either common or even desirable in many cases. Design by committee is rarely a good idea, and I much prefer either design by addition or design by feature / feature batch. Again, those depends on the type of team that I am working on.

Another thing to note is the difference between technological experts and business experts. In both cases, we are talking about developers, but in technological experts are good for one thing, clearing the way so the developers who actually understand the business can get things done, fast.

I will reference again my posts about JFHCI, as a good example of how I think those things should be done.

Yes, I know, 2003 called and asked to get its distribution technology back. Nevertheless, remoting is an extremely useful tool, if you can make several assumptions about the way that you are going to use it.

In my case, I am assuming inter process, local machine configuration, with high expectation of reliability from both ends. Considering that I also need low latency, it seems like an appropriate solution indeed. I was pretty happy about this, until all my integration tests start to break.

After a while, I managed to figure out that the root cause for that is this error: Because of security restrictions, the type XYZ cannot be accessed.

Now, it worked, and it worked for a long time. What the hell is going on?

After thinking about this for a while, I realized that the major thing that changed was that I am now signing my assemblies. And that caused all hell to break lose. I managed to find this post with the solution, but I am still not happy. I really dislike things that can just go and break on me.

I swear, I was just about to back away from the entire thing.

It started with me trying to create a new account. I had to go through about seven screen to do so. Then there was the big warning about gmail accounts not being acceptable, then there were the mandatory formatting of address & phone numbers, to match what their system wanted from me.

I kinda of like their licensing agreement.

Argh, that is so stupid. I am trying to give you money, why are you trying so hard to make this hard on me?

I think that I mentioned that NHibernate Profiler is working mostly by doing some smarts on top of the log output from NHibernate. That is not exactly the case, but that is close enough. The problem with working through the logs is that there are roughly 30 lines of XML that you need to deal with in order to manage this properly.

The first time I sent this to anyone else, he run into problems with the configuration because of very subtle issues. For a while now, I had a ticket saying that I need to document what the failure scenarios are, and how to deal with them.

Today, as I sat down to deal with this ticket, I decided that it is wrong to even try. This is shoving my own problems to my users. I shouldn't do that, if the configuration is hard to do, that is my own issue, and not theirs. I should bear the burden of complexity.

As such, I spent some additional time getting this to work in the smoothest way possible. The end result is that in order to use NHibernate Profiler in your application, all you need to do is add the following line at the application startup (Main, Application_Start, etc).

NHibernateProfiler.Initialize();

That is it :-)

I am currently working on getting a beta version of NH Prof out, but I run into a problem. There are several features that I intend to put into the release version that I didn't have the time to actually put it. Those are usually features that are good to have, but not necessarily important for the actual function of the tool. One of them is saving & loading the captured data. Currently, I am working on more important things than dealing with this, so I didn't implement this.

However, I do want to make it clear that it will be supported, and more than that, I want to make it clear that it it is not there yet.

Using my amazing WPF skills, I manage to whip up the following:

Which is located on a style set on MenuItem. This means that the only thing that I need to do to mark a menu item visually as unusable is to set its Tag attribute to NotImpl. I love this ability.

This is how it looks like:

Remember that I mentioned the difference about working and production quality?

One of the things that separate the two that in production quality software, you don't need to know which buttons not to push. Here is a simple example. For a while now, if you tried to bring up two instances of NH Prof, the second one would crash. That wasn't something that you really want to show the users. Today I got back to doing NH Prof stuff, getting it ready for public beta, and I decided that the first thing to do was to tackle this easy feature.

Doing this is actually not an issue, testing this, however, was a problem. I have two application instances and four layers to go through. Here is the first test:

[Test]
public void When_creating_two_instances_of_application_will_tell_the_other_to_pop_up()
{
	var bus = MockRepository.GenerateStub<IBus>();
	var listener = new NHibernateAppenderRemotingLoggingEventListener(bus);
	listener.Start();

	try 	{ 		var anotherBus = MockRepository.GenerateStub<IBus>(); 		var anotherListener 			= new NHibernateAppenderRemotingLoggingEventListener(anotherBus);
		anotherListener.Start();
		Assert.Fail("Exception was expected");
	}
	catch (AnotherApplicationIsAlreadyRunningAndControlWasMovedToItException)
	{
	}

	bus.AssertWasCalled(x => x.Publish(null),
        options => options.Constraints(Is.TypeOf<BringApplicationToFront>())
		);
}

The logging event listener is the reason that we can't bring up two instances of this. We use this to listen to running applications, and having several of the profilers running at one time isn't going to be helpful. And just to deal with the nitpickers, the four layers I mentioned are: Communication layer, backend, front end, actual user interface.

Here is an example that tests communication between the back end and the front end:

[Test]
public void When_bring_up_to_front_message_is_publish_observer_should_raise_event_for_UI()
{
	var facility = new BusFacility();
	var observer = new ModelBuilderObserver(action => action());
	bool wasBroughtToFront = false;
	observer.ShouldBringApplicationToFront += () => wasBroughtToFront = true;
	facility.Initialize(observer);
	using(facility.Start())
	{
		facility.Bus.Publish(new BringApplicationToFront());
		facility.Bus.WaitForAllMessages();
	}
	Assert.IsTrue(wasBroughtToFront);
}

As for the actual UI code, I am not sure how to test that. I did a manual test, but I am not sure that I am happy about this. Then again, we are talking about testing this line of code:

observer.ShouldBringApplicationToFront += () => Activate();

I can just test that the event was subscribed to, but I don't really see this as valuable.

Slightly revised with help from Matt Campbell:

The quality of a software system is inversely proportional to the amount of money it handles.

I intentionally call it observation vs. law, because I don't think that there is any inherent reason for it to be this way, that is just the way it is.

A while ago Patrick Smacchia posted an analyses of NHibernate 2.0 in NDepends. Go read it, it is interesting, not only because it gives an insight about how to utilize NDepends, but also as a good indication of problematic areas inside NHibernate.

The NHibernate code base is aimed at solving a very complex problem, and I will be the first to admit that there are a lot of improvements that I would be delighted to do if I had infinite time to do so. In fact, some places of the code annoy me to the point where I make a point of putting them up in this blog as an example of what not to do.

The main problem is that, as I said, NHibernate is aimed at solving a very complex problem. And we already know that you can't escape complexity. Where I think NHibernate is making a great job is in dealing with this complexity for you, and making sure that your code is clean and clear.

As such, I can live with imperfections in the code, for as long as I don't hit them. When I do, I take out the hammer and deal with them. But the #1 criterion for the NHibernate code base is that we will make a whole lot of effort to ensure that the client code is clean.

As long as we manage to do that, we are doing a good job.