It is sometimes hard to believe, but I have been giving talks all over the world for quite a while now. It is said that practice makes perfect, and I think that practice has certainly made me a much better presenter.

The story about how I learned to handle public speaking is entertaining, and I get to tell it quite a lot.  But this post is not about that old story, it is about a new story. I have been doing a lot of presentations for a long while now, and I can track how I improved as a speaker since the beginning.

Detailed Bullet Points is probably by far the most common, and usually considered as flawed. This type of presentation is also referred to as Power Point Poetry. You can safely assume that I am not overly fond of this style.

Recently, I have leant much more toward the presentation zen style of slides. For that matter, I consider the slides a far third in the importance in giving a session. The first being the ability to actually talk and the second is good familiarity with the material.

Before the first & second, however, there is something that is far more important, at least to me. And yes, I am aware of the impossibility of priority zero. Language. I am not a native English speaker, and speaking in English, especially public speaking, is not something that came naturally to me. I still remember doing a talk and switching to Hebrew during the introduction without noticing...

But I have been practicing English quite a lot lately, apparently speaking only English for long period of times does help, and it shows. It got to the point where I sometimes automatically speaks in English, which I find highly disturbing at times. Oh, and if someone can explain to me the process in which I can select which language to talk, I would be grateful, I am extremely interested in that, but I have no clue how it works.

Anyway, given that you are actually able to speak coherently in the language that you are going to use, there is one important thing that you must do before you start prepping for a presentation. Decide what is your goal, given your constraints.

Constraints are things like:

• What is the level of the people in the audience?
• What is their familiarity with the subject at hand?
• How complex is the topic?
• How much time do you have?

The goal is affected by your constraints, not the other way around. And the sad thing is that often enough, it is so easy to get it wrong.

The basic problem is that most of the time, it is so bloody hard to get it right. It is easy to spend hours on a topic, because it deserve to have hours dedicated to it. But most often you have an hour or so, and that is it. And in that timeframe, you have to decide what you want to do.

Broadly, there are several options:

• High level vision - what you can do, why you want to do it, how does this help you make your life better. In technical discussion, you might also want to be able to do a demo or two, but you keep it high level, and don't get mired in the code. The main goal is to give the audience the concepts and the understanding.
• Introduction - show what is going on, demos, skim the surface, don't get too deep, with some minimum level of introduction to the concepts that are being exposed. The main goal is to give the audience an actionable start. They can go home and do something with this.
• Detailed overview - this is a focused discussion on a specific topic. Usually this assumes some level of familiarity with the subject from the audience, and we can dive into the details and discuss a topic or two at length. Note that a topic is a small matter, but we can cover it quite well. The goal is to shine a spotlight into a particular area, and give the audience a lot more knowledge about it.
• Blow their mind - despite the name, and the fact that I had done a presentation just like that very recently, I am not sure that I like this style at all. Somehow, I feel that this is cheating. Basically, in this style of presentation, you identify some problem that your presentation can help solve, and then you try to do the best demo you can to get an impressive result. The reason that I feel like cheating is that it is usually an non actionable presentation. You usually can do something with it right away, but you would need to do a lot more to get the real benefits out of this. This also takes a whole lot of time in prepping for this, and you have better be able to judge the audience and see if you get the appropriate reaction. If you can't keep up the pace of the presentation, you are going to flop badly.

In Oredev, I had done three talks, and a workshop, which falls naturally into each of those categories. Peter Hultgren has this to say about my Active Record presentation:

The best presentation was probably “Using Active Record to write less code” by Ayende Rahien, which was cocky and super motivating. Even though I have some experience using ActiveRecord, and pretty much knew about the features he brought up, I had the same “wow” reaction as everyone else did. If you can deliver an ad-hoc presentation which preaches to a converted and makes him want to re-convert, then you’re on to something.

Leaving aside being immensely flattered by him, that was a "blow their mind" approach, which I purposefully tried to stirred the pot. I assumed that calling everyone in the room a criminal would make sure that it wouldn't be a popular presentation, but apparently that was quite popular. The theme of that talk was Persistence is a Solved Problem.

As I said, this is a dangerous technique. Another talk that I did in this style was ReSharper in DevTeach almost a year ago. And that one is a great example of a flopped presentation. I wasn't able to keep up the wow effect, and I basically lost the audience midway through.

In Oredev, I also had the "Producing Production Quality Software", which was a high level talk. That one went well as well, and it mostly involved telling a story. The key part in this presentation is involving the audience. Since I am talking to a crowd of IT guys, it wasn't hard to get them to commiserate with my war stories about production failure.

I also gave a Rhino Mocks presentation, which unfortunately was at the last talk at the last day. Here I made a major mistake, I fail to read the mood of the audience as wasn't able to adjust as well to a crowd that was simply a bit tired to be fully participating. This is something that I should have handled better, which I hope that I'll be able to utilize in the future.

The interesting part about Oredev presentations is that we had only 50 minutes for each presentation. Most other conferences has an hour to an hour and a half. That gives the speaker a lot more time, and it made prepping for Oredev much more... interesting. On the one hand, it is hard to try to squeeze almost fifteen minutes out of a session. On the other, it does mean that you have a very succinct talk if you manage to do so.

That is another important aspect of the constraints that I mentioned before. Which style of presentation you use is greatly influenced by the amount of time that you have. In particular, for most people, showing code is the most time consuming process in the presentation, except writing code. And there is basically few things worse than leaving the audience hanging without any input from you while you are busy typing code.

If you can cut down the writing code part to less than 20 seconds without input to the audience, it will work, otherwise, you need to prepare ahead of time. Something that I like to do for my presentation is to do a lot of ad hoc coding. Sometimes it works, sometimes it doesn't.

When it does work, it tend to impress people. When it doesn't work, I crash & burn :-) I try to have a backup plan for such scenarios, but I need to actually notice that I need the time to move to it.  Another tip, you have ten seconds to debug a problem in your presentation, if you try to do anything more than that, you better back up, blame Murphy, and move on.

For that matter, watch the audience. You need to match the presentation to the people actually listening to it. Always start a presentation by syncing up with the audience. Who are they? What do they know about the subject? Tell them what you are going to talk about, how this is going to help make their life better.

In the timeframe of most presentations, you can't really give a whole lot of information. You just don't have enough time, and worse, you don't have a consistent audience, which would allow you to start from a level ground. What you can do, however, is to raise their interest. If after a talk I give, people in the audience go home (or on next Monday), and start looking up the things that I talked about, then I know that I have been successful.

A while ago I worked at a bank, doing stuff there, and I was exposed to their internal IT structure. As a result of that experience, I decided that I will never put any money in that bank. I am in no way naive enough to think that the situation is different in other banks, but at least I didn't know how bad it was. In fact, that experience has led me to the following observation:

There is a direct reverse relationship between the amount of money a piece of code handles and its quality.

The biggest bank in Israel just had about 60 hours of downtime. Oh, and it also provide computing services for a couple of other banks as well, so we had three major banks down for over two days. The major bank, Hapoalim, happen to be my bank as well, and downtime in this scenario means that all of the systems in the bank were down. From credit card processing to the internal systems and from trading systems to their online presence and their customer service.

From what I was able to find out, they managed to mess up an upgrade, and went down hard. I was personally affected by this when I came to Israel on Sunday's morning, I wasn't able to withdraw any money, and my credit cards weren't worth the plastic they are made of (a bit of a problem when I need a cab to go home). I am scared to think what would have happened if I was still abroad, and my bank is basically in system meltdown and inaccessible.

I was at the bank yesterday, one of the few times that I actually had to physically go there, and I was told that this is the first time that they had such a problem ever, and the people I was speaking with has more than 30 years of working for the bank.

I am dying to know what exactly happened, not that I expect that I ever will, but professional curiosity is eating me up. My personal estimate of the damage to the bank is upward of 250 million, in addition to reputation & trust damage. That doesn't take into account lawsuits that are going to be filed against the bank, nor does it take into account the additional costs that they are going to incur as a result of that just from what the auditors are going to do to them.

Oh, conspiracy theories are flourishing, but that most damning piece as far as I am concern is how little attention the media has paid for this issue overall.

Leaving aside the actual cause, I am now much more concern with the disaster recovery procedures there...

I don't generally comments on politics in this blog, but this is something that I cannot ignore.

I was just watching the evening news, and I saw Ehud Barak, Israel's Minister of Security, state (for the record!) that the goal of the current government is to reduce the number of missile launched on Israel to 10 - 7 a month.

Allow me to repeat that.

The Minister of Security for Israel, as part of answering an inquiry for parliament, has stated the official position of the government. And that government goal, the thing it strive for, is to to have missiles launched on Israel.

I almost puked when I heard that, and I am still furious.

On of the things that I like most about conference is that they are the place to meet and exchange a whole boat load of ideas with a large number of people. Most of the time, this is actually done on a normal level, just far more frequently than usually happen. Just this is a reason enough to visit conferences.

Sometimes, however, you get into a conversation that really open your mind. That is what Aslam Khan managed to do to me in about five minutes of hallway conversation. This short talk literally opened up for me a whole new way of thinking about the utilization of aspects and other behavioral patterns. I am going to try explaining this in this post.

Aspects are a way to add behavior to an object. Usually we are talking about being able to add pre and post actions to method calls on the fly. Aspects are commonly used to handle cross cutting infrastructure concerns. The typical examples are: logging, transactions, security and caching.

In the past, I have put domain logic in aspects, and has come to regret it very much, to the point where I believed that the only reason to use aspects is to handle cross cutting infrastructure concerns. Aslam changed my view on that.

Let us take the typical bank account example, with the Withdraw method. Ideally, I want the Withdraw method to contain just the core logic relating to its operation, so it would look something like this:

public virtual Status Withdraw(Money money)
{
	ammountInAccount -= money;
        return Status.Success;
}

However, what is going to happen when we have the following business role?

You may not withdraw from the account in the first week after is was opened, you may only deposit.

As usual, stupid business rule, but the example doesn't matter. The question is, where does this behavior belongs? Something that you should take into account is that there are likely to be many such rules, and any answer that you give should handle this scenario gracefully.

According to Aslam, the answer for this is in an aspect. Something like this:

public class MayNotWithdrawFromAccountOnFirstWeek : AnAspectOf<Account> // this is invoked on Account.Withdraw method
{	
	public override void BeforeExecution()
	{
		if( (DateTime.Now - Entity.DateCreated).Days > 7 )
			ReturnValue = Status.ActionCancelled;
	}
}

This allow to maintain both the single responsibility principle and create clean separation between the core entity behavior and extended behavior, which is usually implemented in a service layer somewhere.

My first thought when I heard this (I have a deep rooted suspicion of aspects for domain logic, remember) is that I want to make this explicit, so have something like the entity publish some sort of event that the container can route to all subscribers. Thinking about this further, I realize that the code to actually raise the event is exactly the kind of cross cutting technological concern that I want to use an aspect for anyway.

I am not sure about the implications of this technique, but it resonates very well with my JFHCI notion.

In response to Davy's post about the rise of interesting in NHibernate,I decided to run the numbers.

Nine months ago we created the NHibernate Users, which has taken off quite nicely, with over thousand members and a very active community.

For that matter, the stats for NHibernate downloads are quite nice as well.

The dip just toward the end is just before we released NHibernate 2.0.

Awesome!

I was sitting in Claudio Perrone's talk about agile tales of creative customer collaboration. It was a good talk, and the first one that I saw that actually had a teaser video.

One statement that he said really caught my attention: Parallel Monologues.

I really like the term :-)

I am writing this in a bar in Malmo. Sitting with a bunch of guys and discussing software methodologies. I had an observation that I really feel that I should share.

Most software methodologies are making a lot of implicit assumptions. The most common implicit assumption is that the people working on the software are Good people. That is, people who care, know how and willing to do.

This work, quite well, in the early adopters phase, since most early adopters trend toward these set of qualities anyway. The problem is when the early adoption phase is over, and the methodologies hit the main stream. At this point, the implicit assumption about Good people no longer hold true.

Just to annoy Scott Bellware, here is a big problem that I can find with Lean just from the things that I heard about Lean from him. Toyota hires the top 2% of the engineers that they interview. A lot of the methodology assume a competent team, or at the very least, a competent chief engineer.

I don't think that I need to state that competency is not universal.

If your methodology assumes competence, and most of the methodologies that we (as in I and like minded people) would find favorable do assume competence, it is going to fail in the treches.

Quite often, people remark to me that I set unreasonable time estimates for work because I am somehow much better than anyone else. I strongly disagree with this statement. Both the qualitative assessment of my skills, and that this is an unreasonable timeframe.

There are several things that I am doing that I think that people are ignoring. One of them is not starting from zero, but starting already at high speed. But that isn't the major thing here. The major thing is that people fail to notice what I am giving those estimates very well defined things. You want to build an IoC container? It takes less than ten minutes to build a useful container. And I built an application on top of a container that wasn't much more complex than that.

That isn't a good IoC tool by any means, but it took very little time to build, and it works. If you click the link to see the container code, the container whose code you are reading is going to be involved in serving the code. It works and it fits to purpose.

That is a major thing to remember. A lot of the really useful concepts are trivially simple to build if what you need is a very simple. You can do that in a day.

And I include in this concepts such as OR/M, Aspect Orientation, IoC, Logging, Hot Code Swapping, Message Buses, Search Engines, Event Brokers and many other basic infrastructures.

The catch is that in a day, you get something that works, for the scenario that you need it for. If you want to take it to the next level, however, this requires a much higher degree of investment.

Coming back to the title of this post, you either do it in a day, or you dedicate three months for it.

I had a (great) talk yesterday, introducing Active Record. During this talk, I reused Jeremy's statements about data access. If you write data access code, you are stealing from your client.

Frans Bouma puts it beautifully:

No customer should accept that the team hired for writing the line-of-business application has spend time on writing a report-control or for example a grid control. So why should a customer accept to pay for time spend on other plumbing code? Just because the customer doesn't know any better? If so, isn't that erm... taking advantage of the inability of the customer to judge what the 'software guys' did was correct?

The context for Frans' post was a design decision from the Entity Framework team. I read Frans' post first, and I didn't quite know how to react to it, until I saw what the proposed design is. You can read the entire EF post here, but I'll try to summarize it so you can actually understand the point without going and reading the whole thing.

The problem is supporting change tracking in disconnected scenarios. In particular, you take an object from the database and send it to the presentation layer, some time later, you get the object from the presentation layer and persist it to the database again. There is a whole host of bad practices and really bad design decisions that are implicit in the problem statement, but we will leave that alone for now.

This is still a pretty common scenario, and it is more than reasonable that you would want your data access approach to support this.

Here is how you do this using NHibernate:

session.Merge( entityFromPresentationLayer );

Frans' LLBLGen support a very similar feature. In other words, it is the business of the data access framework to do this, none of the developer's business to do any such thing.

The current proposed EF design problem can be summarized in a single line.

context.ChangeRelationship(
customer1,
order1,
c=>c.Orders,
EntityState.Added);

This is code that you as the user of EF, is supposed to write.

If you write this type of code, you are stealing from your client.

This design violates the Infrastructure Responsibility Principle: Developers doesn't write infrastructure code for supported scenarios.

In other words, it is okay not to support a feature, but it is not okay to say that this is how you are supporting a feature.

This Is Broken, By Design

I spent a great day at the Oredev conference, and even a greater evening.

It started with a full day in the ALT.Net track, in which we agreed that ALT.Net shouldn't actually exist, and the main purpose of ALT.Net is to change its nature from alternative practices to merely a label for the set of principles and practices that we believe in.

I think that the name ALT.Net will change its meaning in the near to medium future, and change from being alternative to being an alternative to the mainstream .Net culture to subsuming the .Net culture, at least the high end of it. At that point, I think that ALT.Net will no longer be alternative, but the actual name will still be used as a label for this set of practices that ALT.Net currently represent.

Moving on from there, we (me, Glenn and Scott) had a great dinner, followed by several hours at a bar, just talking with speakers and attendees from Oredev.

I don't know if I mentioned it already, but just about everyone I met so far is very friendly.

After spending several hours in a pleasant conversation over bear in the bar, we got kicked out (something that seem to happen to me regularly now), so a bunch of guys (and one gal) went to a night club. I will just hint that Scott Bellware and bicycles doesn't add up in a coherent discussion.

The night club itself was great. Expect for Creepy Guy.

Let me put it this way, Creepy Guy made me think about date rape drugs and rectum reconstruction surgery. He made me extremely uncomfortable. I don't think I would have liked the retired-cremationist anyway, but I haven't had the chance to meet people as obnoxious and spooky as this guy in a long time.

Luckily, he was just one guy, and we were able to foster him off to a designated victim at a time. I blame the night club for my current state of non drunkness.

If I can still type in English, then I am not drunk.

Anyway, so far, I am really enjoying Øredev. I have two talks to give tomorrow, and it is now 3:30 AM local time, so I better lay off the laptop and get some sleep. If you are in Øredev, you might want to check my sessions for the amusement value alone.

Oh, and since I am going to be in DevTeach in a week or two, I dare the DevTeach attendees to get me drunker than that...