Unfortunately, change is not that simple. Most people are hesitant to change, they create workarounds for problems they have and trying to make them change often fails. Resistance to change is not about politics or opposing views. Most of the attempts that try to change something and fails do so not because the change was bad, but because of the way the change process itself was managed. Here are three very important facts about change that are often overlooked, leading to almost certain failure in changing.

1. Your vision is not their vision

In the words of my friend Joakim Karlsson, change is a pull system. It may be obvious to you that if your team or organization would just do this change, you would all be much more effective. But do not expect your coworkers/manager/friends (or whoever you want to change (with)) to think so. If you try to push your change on them you are almost certain to fail.

This does not mean that you should just sit back and wait of course. Instead you need to convince them that they need the change. But it is not enough to say that things will get better, or that this new technology is proven to be better. You have to put it in context for each specific individual or group you are trying to convince. What problems are they having today, and how will the future created by this change affect them specifically? The more specific you can be about describing both the current status quo, the change and most importantly the improved future from their perspective the more likely you are to get people interested in the change. And then you will not need to push the change on them, they will be requesting it to happen.

2. It gets worse before it gets better

So you managed to convince your boss to try your idea. He will be back in a week to follow up and see the effects of it. Or maybe you did not even try convincing anyone. After all, when the change is implemented who could possibly have any objection to it when things are already much better?

Wrong! No matter how great your idea truly is, no matter how much improvement it means to your effectiveness, changing what you have now always hurts your effectiveness in the short run. People are used to doing things one way and it does not matter if that is an ineffective way of doing them, if they are forced to change they will do things worse for some time until they learn the new way and settle in with it.

There is lots to say about this curve and how to help people through it, as well as how to work to shorten the time between the change and when you are back at the starting level. For now though we will just keep it at accepting and realizing the importance of this curve. Do not expect immediate gains from the change.

3. It takes time to see the benefits

Finally, you have managed to convince and get people interested in the change, and all of you have also understood that it will be a time of chaos before things get better. But the question is, when has it gotten better? Or more importantly, when can we start reaping the benefits of the change?

It is very easy to think that as soon as the period P1 is over it will all be ok. But you have to remember that during P1 you lost effectiveness. Many change efforts fail because they expect net gains at this stage. But net gains are not achieved until you go through the period P2. Instead of getting surprised by this, set your goals for the end of P2 and keep working to support the change efforts all the way.

Keep these three facts in mind when you plan your change and improvement efforts and you will have a much better chance of succeeding with them.

For instance, you might choose to do a timeline to gather data, then a brainstorming activity to generate ideas for improvements and finally a dot-vote to decide what to do. While this can work just fine, I have found that when I am able to combine several activities so they build upon each other the result can be much better. Here is one example of how this can be achieved.

This week I facilitated a retrospective for the new development team that I have assembled at work. This was the first time that this team did a retrospective after working together for four weeks and I wanted them to start thinking about how satisfied they are with how things are working out. After getting started with an introduction to retrospectives and checking in we did a quick anonymous vote for how satisfied they were with work, in four dimensions. I chose two dimensions regarding the product increment they completed (Quality and Quantity of the increment) and two dimensions regarding how it was achieved (Teamwork and Support (-ing Environment)). Every one voted 1-5, I tallied the votes and then created a Satisfaction Histogram^[1] on a flip chart.

After a quick discussion about the results I hung the histogram on the wall and we then moved on to a second activity for gathering data, Diana Larsen’s FRIM which is one of my favorites for this. At this stage we did not talk more about the dimensions of satisfaction, they just wrote down good and bad things that happened during the four weeks and posted them on a grid according to frequency and impact. We finished with a good discussion of patterns and themes on the grid.

While the group was busy with the FRIM activity I prepared four flip charts for the next activity, doing a Force Field Analysis^[1]. For each one of the dimensions I had written the name at the top and then divided the chart into two sides. On the left (negative side) were forces that was restraining the group’s satisfaction in that dimension of work, and on the right (positive side) were forces that was reinforcing it. Now I asked the group to move the post-it notes from the FRIM grid to these flip charts. They also ranked them (using both frequency and impact plus a bit of intuitive “gut feeling”) to show which forces were larger than others.

This set of activities is an example of how you can move back and forth between gathering data and generating insights, to really get as complete a picture as you can and drill into it to really understand it. When the group was done they had a good idea of which forces were the most important to focus on and we could move into the phase of coming up with actions to do during the next iteration.

One interesting insight that one of the participants made was that it was interesting to see that there were only positive post-it notes for the dimension that the group initially voted the highest satisfaction for. Their initial instinctive feelings turned out to be very similar to the much more detailed picture they created through multiple rounds of thinking and analyzing, which was pretty cool.

Credits/references
[1] Agile Retrospectives: Making Teams Great, Diana Larsen and Esther Derby

Could you draw a copy of the image above without seeing it, acting only on someone’s description of it? What if the other person was only allowed to describe it in written text, and you are not allowed to talk to each other at all? That is the idea of an experiential exercise that I like to include in classes and workshops when I want the participants to experience the importance of instant feedback.

Basic setup

Here is the way I usually use it these days. First, the participants form pairs. One will take the role of developer, the other will be the customer. I then tell them that they will be “developing” drawings, by copying an original drawing to a blank paper. The customer is the only one who will be allowed to see original drawing, and the developer is the only one who will be allowed to draw. I then inform them that we will run two rounds.

Round 1

In the first round the customer must create a specification for the developer, by describing the original drawing in writing. Only text, no symbols or drawings. The customer and developer are not allowed to talk to each other during the entire round.

After five minutes the requirements phase is finished and they move into the implementation phase, when the developer is allowed to start drawing (if they have received a specification of course). The customer is allowed to watch as the developer draws, and if they want to they can provide further instructions in writing throughout the implementation phase. I usually place the developers and customers in different rooms and instruct the customers that they are only allowed to write at their own “desks”.

After ten minutes the implementation phase is finished and I bring everyone together, standing with their pair colleague. Each customer shows their original drawing and the developer shows their produced copy, and we have a quick vote to decide which pair got the best result.

Round 2

I ask the pairs if they want to change roles for the second round, and then introduce the new rules. In this round the customer and developer will sit next to each other. The basic rules are the same, only the customer can see the original drawing and only the developer may draw (e.g. touch the pen), but this time they can communicate in any way they want. They can talk directly and the customer can even point to the paper. The full round lasts for ten minutes and there is no requirements phase, they can immediately start talking and drawing.

Insights and learning points

Apart from the obvious fact that the results were much better in round 2, with less time to complete them, there are also many other insights that can be made from this exercise. Depending on how you play it some of them might be more clear than others. Here are a few things that usually come up when we debrief the exercise (always debrief!).

• Following made-up rules: We often find ourselves following “rules” that do not even exist, we made them up ourselves. Sometimes customers think they are not allowed to use measurement units (such as “3 centimeters wide”) to describe the drawing, even though no such rule is given.
• Creating a common language: In the pause between the two rounds the pair will often talk about their drawing and find common ways they have of describing something. For instance, some will call the solid blue circle in the drawing above a donut. This common “language” makes it easier to describe abstract things such as a drawing (or software).
• Iterating the drawing: This usually happens during the second round, where some pairs sometimes adopt a process of first quickly sketching out the basic layout of the shapes to have something to point to and discuss. They will then start on a new paper and make a better drawing, and possibly iterate like this multiple times.
• “This is just a simulation”: Very often this comes up in some way. One favorite of mine is when people say that they sit in different buildings so they have to communicate by writing to each other. Asking them if the exercise have changed their mind on the value of clearer communication and instant feedback is usually enough to get them started on planning how to make it work anyway.

Variations

I usually run the exercise the way I have described above, as part of an introduction to agile methodologies, to show the difference between trying to communicate by written specifications versus sitting down together and working collaboratively. There are lots of ways it can be altered depending on what insights and learning you want the participants to get from it. Here are a few that I have tried and some that I thought about while writing this.

• Improving through retrospectives: One of my favorite subjects is retrospectives, and variations of this exercise can help teach participants how to use them. For instance, run several shorter rounds and do a retrospective between each one, where the the pairs learn and find improvements to their process. You can choose to only work with written specifications for instance, and let the pairs use the retrospectives to discuss how the specs can be improved and a common language can be used in them.
• Include a messenger: In round 1 use a messenger (maybe call them Project Manager, or Business Analyst) who is responsible for delivering the customers written specifications to the developer and giving the customer feedback on the result. The customer is not allowed to move from his desk, so he never sees the work as it progresses and have to rely on the information from the messenger.
• Involvement of product owner in development: One of the worst anti-patterns I know is the product owner who takes part in the planning of an iteration and then disappears, until he then shows up at the demo and disqualifies the work the team has done during the iteration. Real product owners take part in the daily work of the team, and it is very simple to show this with a variation of this exercise.
• Information loss in multiple handoff situations: Let the customer describe the drawing (probably should be a simpler drawing in this case) to a business analyst, who describes it to an architect, who then describes it to a designer, who describes it to the developer (introduce as many levels as you wish) and see what results you get.

When thinking about variations I think it is important to remember that an exercise should be as simple as possible for whatever learning it should support. Remove any element that does not directly support that learning point. If you have more ideas for variations of this exercise please post a comment. Thanks!

I have uploaded a presentation on Slideshare that introduces the exercise and includes some sample drawings (basic shapes laid out in various ways) you can use.

Credits
I got the original inspiration for this exercise from James Shore and his exercise called Offing the Off-Site Customer.

Alistair Cockburn also has a somewhat similar exercise he calls The Draw-This-Drawing Game which is a bit more complex and used for more specific learning points.

This blog post is part of my Duoblog Series. For each topic I ask someone I know and respect as an expert on that topic to write a blog post with the same title as my post. We then post them at the same time without knowing what the other person wrote.

For advice on creating a great presentation I turn to Claudio Perrone. When I first met Claudio two years ago he had just been accepted to speak at a conference, his first public speaking engagement. Claudio is an amazing learner and quickly studied everything from storytelling and moviescript writing to creating powerful visual presentations. I have been fortunate enough to see him present a couple of times so I know that he can really engage an audience with stunning visuals and a great story.

Read Claudio Perrone’s answer to “What is the secret of great presentations” on his blog.

So much to say, so little time

Picture this: You have been given a chance to present your company’s new product in a 45 min presentation. You want to create a great presentation to make people really enthusiastic about it. So, you fire up Powerpoint and start making bullet points for everything fantastic you can say about your product. The more great things you mention, the better people will feel about it, right?

Unfortunately, this seems to be what a lot of presentations are about. The speaker tries to mention as many things as possible in the time they have available. Each slide has so many bullets that she does not even remember to mention all of them. When time runs out she jumps to the final slide to wrap things up, while mumbling that there were more interesting things to say if only there had been more time. The audience remembers a fraction of what was said, and probably have a hard time summarizing it.

I believe that this happens when the speaker starts by considering how much time is available for the presentation and then works to fill that time with interesting stuff, rather than the other way round.

Creating a great presentation

Start by defining what you would say if you only had a short moment to say it, no matter how much time you actually have for your presentation. There is probably a specific reason why you are giving this presentation. Whether you are talking about a new technology or an idea you have, there is something about it that you think is important enough that you want to tell others about it. This is the core message you should deliver, and it should take no longer than 45 seconds to deliver it. If you can make people more enthusiastic and wanting to hear more about the topic then you know you have succeeded, and you are ready to add more things to the presentation.

If you have more time available, think about how you can make that message clearer and more powerful. Resist the temptation to add another core message to the presentation. Instead add some supporting ideas that give some more detail, still with the core message in focus. To avoid adding too much consider what you would say if you had 10 minutes to present your idea. If you have even more time then add another level of detail, this time giving further support for the ideas introduced in the previous level. In this way the presentation scales up, and everything you say is still related to the one central idea you want people to learn from your presentation.

A powerful message that people will remember

Now that you have taken a different approach to creating your presentation you will need to think about how to frame the core message so that the audience will understand and remember it.

Put yourself in the shoes of your audience and ask “What’s in it for me?”. If you do not give people a reason to remember it, why would they? Put your message into a context that the audience can relate to. Describe a situation or problem that they will recognize from their own life, and then present your idea and how it solves or relates to that problem.

Introduce the core message very early in the presentation, right after setting up the context it should be delivered in. Also repeat it throughout the presentation. Specifically make sure that you end with the core message again, since people generally remember best what they learn at the start and end of a learning session.

Finally, do not be afraid to use Powerpoint or other visual aid. People favor different learning modes (auditory, visual and kinesthetic), and multi-sensory learning is a powerful memory aid. Seeing keywords in written form, accompanied by powerful images, can help your audience remember better. The important thing is to avoid confusing presentation with documentation. A bullet list with some key points is a great aid when later reviewing something, but that does not mean it has to be a part of the actual presentation. Instead provide a separate file for documentation.

Scale your presentation up from the one thing people should learn

In summary, creating a great presentation starts with a clear and concise core message that the audience can relate to. The presentation is then scaled up level by level to add more detail, all the time repeating that core message. If you feel the time is to short, make it shorter.

I will be updating this post with links to each duoblog post as they are written in the future. Stay tuned!

Duoblog posts

• 2009-06-29: What is the secret of great presentations?, with Claudio Perrone

The problem with considering pair programming as something we decide to do in some situations, as opposed to deciding not to do it in some situations, is that it is too easy to stick with the norm by not making that decision. “This task is too simple, that task is too complex and requires some serious thinking, I do not feel like pairing today” are all easy excuses to use when you do not have to answer why. A conscious decision of disregarding a work standard requires much more than “not feeling like it today”.

When I propose that pair programming should be the norm people often react by listing situations where it would be wrong and wasteful (according to them at least) or by identifying problems with working with someone else all the time (“what if someone smells bad?”), almost regressing to an anti-pairing opinion. I think this is because this concept is so foreign to what we have been taught for so long, and that most pro-pairing people have actually not tried pairing as the standard way of working like I propose. To this day I have never met anyone who have actually tried working this way for at least a month but would like to work any other way.

For a great story of someone who did try real pair programming I really recommend Rod Hilton’s post I Love Pair Programming. I’ll end with a quote from that post:

I see pairing work so well every day that I consider my career prior to my current job to have consisted mostly of wasting time.

As I said, it should be quite obvious that most people consider their own code to be better than someone else’s code, but I think we can make some profound realizations from looking into this more closely. There are two questions that are important to think about here. First, what is the effect of this issue? Second, how do we use this knowledge when working with a development team to help them produce better code?

An escalating mess
If I encounter some bad code, I will try and make it better. Since I believe my code to be good code, I will of course try and change the bad code to become more like my code. So, the code is better and everyone wins, right? Well, what about the other guy? He sees my code, and since from his perspective his code is better than mine, he will of course try and change it so it becomes more like his code. And round and round it goes. Each of us are trying to make things better, but together we are actually producing an ever escalating mess.

So, the important question then is how can we help developers realize that their good code might not be the best for the team as a whole? My bet is on communication. Using practices of communication and reflection between the developers in a team, we can create a common understanding of what good code means to us, and break the escalation.

Talk about code
Any time spent away from programming, instead talking about code and coding, is time well spent in a development team. If we want to get a common understanding of what good code is, then we need to have some formal structures in place to insure that this talking about code happens. Do you use pair-programming as the default mode of working? Do you do code reviews, where everyone on the team sits down and talks about some piece of code to learn from each other about how it could be improved? Do you collectively break down user stories (or other requirements) into tasks, using CRC design and similar techniques for exploring what a good design would be? Are you running a study circle?

What techniques and practices does your team use to make sure that you talk about code enough to have a common understanding of what good code means to you?

An anti pattern is a repeated pattern of actions, a process or structure that initially appears to be beneficial

The Helpful Teacher

Introduction
“If we would only use test-driven development, our design would be better.”
As the self-designated technical leader of your team, you are constantly trying to help your colleagues understand and use good practices for writing high quality code. Even so, the code base is a mess and it is not getting any better. You have tried everything, from buying them books (with your own pocket money!) to showing them your own great code during a monthly meeting. The best you have managed is to convince some of them to try, but after a short while they always give up while telling you that it does not work. You are back to square one, or worse since now there are people saying that the practices you are promoting does not even work!

Description
Studies in psychology* have shown that if we ask a person about their ability and competence in some skill, most people would estimate themselves as ranking above the average. (For an example, try asking people about their driving skills.) If we ask a group of people to estimate their own competence relative to the rest of the group, again most people consider themselves to be among the “better part” of the group. In fact, as the above referenced study shows, even the most unskilled people estimate themselves above average, because coupled to the lack of competence is a lack of awareness and understanding of that skill.

To be able to teach someone to use a new skill, they must at least see some need for it. Otherwise, from their perspective, you are only trying to push something not needed on them. Since they are unaware of the problem you are trying to solve, and therefore cannot distinguish your proposed solution from their defunct practices, all of your teaching goes in through one ear and directly out the other. “We are practicing test-driven development. We write tests in a Word document and run them manually before release.”

Refactored Solution
Before you can teach someone a new skill they must become aware of the need for the skill and their own deficiencies in that area. In other words, if you want to promote good technical practices for writing quality code in your team, you must first talk about the need for high code quality. The team needs to have a common understanding of what code quality means to them, otherwise everyone will just think that they are writing quality code and they do not need to learn new practices for improving on it.

Here are a couple of things you can try with your team to increase awareness on the value of high code quality, and to create a common understanding of what it means to your team. The thing in common between them is that they all encourage reflection and discussion.

• Pair-programming
  
  The mother of all knowledge-sharing techniques. If you want to spread an idea to your colleagues you should never sit alone and program. No matter how nice code you write no one is going to notice it, and the practices you follow to achieve it will be completely invisible to the others. Try and spend as much of your time as possible working together with someone else. Do not push for all the practices you would like everyone to use, but use the opportunity to show your partner what you can do and the great results that follow.




• Code Reviews
  
  Lots of organizations use code reviews as a way to achieve higher code quality. However, in my experience they are used in a command-and-control way, where you as the developer submit your code for review to the mighty architect, who then returns it with a number of things for you to fix. While some bugs and other problems can be avoided this way (depending on how much time the reviewer has to look into the code), it is not an efficient way of promoting high code quality in a team.

  Instead, schedule a regular meeting where the entire team meets to review and discuss some piece of code from your project. As an alternative you can pick some open source project and review code from there. That way no one in the room is criticized, and it is easier to have open discussions about issues in the code sample. Rotate the role of selecting the code to be reviewed, make sure everyone has the code in advance to review ahead of the meeting, and then spend an hour or two discussing it together over coffee and a snack. If you want to you can follow up by actually implementing the improvements discussed in the meeting.

• Coding Guidelines
  
  Again, most teams have a coding guideline that prescribes what is good code. They can contain things such as naming guidelines, where to put the curly braces and how many spaces the indentation should use. Sadly though, these are documents written a long time ago, by someone who is not part of the team or sometimes even no longer in the organization. As can be expected, they are not meticulously followed and it is not uncommon for people to be completely unaware of their existence.

  Creating a coding guideline for a team should be a collaborative activity for that team. Gather everyone once a month, discuss what people think is important when writing code and find out what everyone will agree to do. Write this down, preferably on large flip-charts posted in the team room. After a month, meet again and continue the discussion. It is not really the results that are the most important, the discussions are where awareness and understanding is spread throughout the team.

If you can create awareness on the need for high code quality you will not need to teach your colleagues how to do it. They will already want to learn, and all you have to do is answer their questions. (Not quite, but lets not get into that here.)

Things are changing. We are closing down Blueplane after two fun and interesting years. I have had a great time and learned a lot and I am sure my colleagues would say the same (here is what Andrés and Joakim say). Now I am looking forward to a new beginning, although I do not know where right now. If you have an idea or suggestion, please let me know. I’d love to talk.

The simplest way of doing this is to simply ask each participant to say something, for instance describe the past iteration in just one word. This activity, and some variations of it, is described as the Checkin activity in Agile Retrospectives, by Esther Derby and Diana Larsen.

However, if the group are becoming more used to participating in retrospectives, this activity can feel a little boring if used every time. This is a perfect time to spice it up with some more creativity from the participants. By having people draw something and then describe why the drew that specific picture, not only do we get a more rich picture (no pun intended) of their mood and feelings, but it also starts the creative process in everyone’s head.

Purpose
Invite participants to be active participants of the retrospective, and help them to get in a creative thinking state. Share the mood and thoughts people have with the rest of the group, including the retrospective leader.

Description
The retrospective leader asks participants to think about how they would describe the past iteration. Each person then draws a simple picture to symbolize their answer. Finally, in a round-robin fashion, everyone shows their drawing and describes what it shows.

Time needed
Ten to twenty minutes.

Materials needed
I recommend that you supply each participant with a magnetic drawing board (or even Doodle Pro for more size). A simple piece of paper and a pen could of course also work, but see the Motivation section below.

Steps

• Ask the participants a question. You could ask them about their perceptions of the past iteration, or just their current feelings. Depending on the situation, you might want to hear about their feelings of this retrospective or just the work that was done.
• Tell everyone to draw a picture that symbolize their answer.
• When they are done (or time is up), ask them in turn to describe their picture to the rest of the group. Some will just say what it shows, others might describe why they drew that specific picture.
• Listen carefully to signals indicating a safety concern. If necessary, follow up with an activity to create more safety for the retrospective.

Motivation
In Pragmatic Thinking & Learning, Andy Hunt tells us to “add sensory experience to engage more parts of the brain” in problem solving and creativity. He goes on to write that “when you involve an addition input mode, you are activating more areas of the brain – you’re bringing more processing power online [...]“. So by drawing our thoughts and feelings, instead of just speaking them, we are thinking more effectively on this ‘problem’, and also setting our brains up for creative work.

And of course, a picture says more than a thousand words! In my own experience, people who can seem very shy and quiet often draw very descriptive pictures, and are normally quite happy to talk about them.

The question of using simple pen and paper or something like a magnetic drawing board comes down to the purpose of the activity, and the specific situation you are in. The ease with which you can erase a drawing board can create a sense of safety. “It does not matter if you cannot draw very well, it is just a doodle that will be gone in a minute.” The playful nature of it, a children’s toy, also helps in this regard.

On the other hand, you might want to use the drawings later in the retrospective for some other activity, or even bring them back to the team room, in which case paper trumps.

Variants
Two specific variations of this that I know of are the Project Weather activity (I will talk about this in an upcoming post) and my friend Michael‘s Car Instrument Board activity (which I will let him write up a description for himself).

Creativity++
Alt. 1: To really get the creative thoughts going, have the participants pair up to create a drawing together two-and-two. Tell each pair to take turns adding something to the drawing. You can start them off by giving them a subject to draw, such as an animal symbolizing the past iteration. The other person then gets to add something to the drawing to change it, for instance another animal trying to eat the first. The first person ‘defends’ by adding something more to the drawing, and on it goes. After discussing their thoughts and the drawing, the pair then presents it to the rest of the group.

Alt. 2: If you only have one drawing board, and preferably a large one, start by letting the first participant draw something (or do it yourself). The board is then passed to the next person who is not allowed to erase it, but must add to the picture. Everyone gets a turn to add to the complete picture!

Finally, I also want to thank my friend Erik Emmerfors for drawing the great comic strip describing the story of the incompetent bank robber. For more information on what this story has to do with my talk, see the summary flyer on the resources page.

For a couple of weeks now I have been deliberately trying to become more effective by improving focus during daily work. I have had a lot of inspiration from Staffan Nöteberg, whose book Pomodoro Technique Illustrated is a great read. I have tried using the Pomodoro Technique a bit, but for various reasons (one being synchronizing with my colleagues) I’m trying other similar techniques such as PCEO now. Regardless of which technique I have been using I have also tried using some technology to help me focus, and that is what I wanted to write a quick post about here. Specifically there are two applications, Spaces and Quicksilver, that I have been semi-using on my Mac for a long time, but not really been able to see or draw any real benefit from.

Focus on the task at hand

When I am working I want to be able to focus on the specific task that I am doing right now. For instance, if I am writing an article I want to have Textmate (or some other application for writing) running, perhaps a couple of browser windows/tabs with some information I need for the article, and perhaps a Finder window. Just things relevant to this task, and for those applications that can have multiple windows or tabs only the relevant windows.

What I do not want to see is iTunes, Mail, an IM application, lots of browser windows/tabs with “other stuff” not relevant for this task, a development environment, Finder windows for other things, my note-taking application or anything else that could steal my focus if I would look at them.

A simple solution is of course to simply quit all these other applications. But that means it will take a lot longer to switch context to other tasks, or catch up on mail and other communication during a quick break. And perhaps I do want iTunes running since music helps me focus, I just do not want to see it because I can easily get stuck navigating songs. Minimizing all these applications is not much better than closing them, since it still makes it difficult with context switching.

The solution for me has been Spaces, the built-in virtual desktop application in Mac OS X Leopard. Using Spaces, I have arranged my desktops according to tasks. The basic setup has three desktops that always exist:

• My first desktop starts out blank. This is where I work.
• The second desktop is my communication hub. Mail, IM, Twitter, RSS reader etc, all those kind of applications are normally always running here. I also have my calendar and todo’s open and showing here all the time.
• My third desktop is my reading place. Articles, blog posts etc that I defer reading until later are dumped here.

At any given time, I normally have a couple of other desktops created. For instance, since I am interested in photography I normally have a number of browser windows open specifically for reading about photography, and also for following different communities that I take part in. I want to be able to quickly overview what is going on in that area, so I more or less always have a separate desktop dedicated for that. Other ongoing work such as sales usually have a dedicated desktop as well.

More importantly, when I am working on some task (on desktop #1) and decide to postpone it for later, I usually create a new desktop and dump everything there. That way I am ready to start a new task with an empty desktop, and I can easily get everything back when I decide to switch back to the previous task.

Finally, I really like having a communication and planning desktop. This is where I go when I come back from a quick break, to get an overview of any changes that might affect my planning.

Recovering gracefully from interruptions

When I am focused on something, possibly in a nice state of flow, I do not want to lose that focus to an interruption I did not plan for (breaks should be planned often to reflect and re-plan as necessary). However, interruptions cannot simply be ignored. The Pomodoro technique describes some good principles for handling internal and external interruptions. Usually it comes down to making a note of whatever was so important to interrupt you, and scheduling time for taking care of it later.

However, there might be some interruptions that I want to act on immediately. For instance, something as simple as iTunes switching to a song that I do not want to listen to right now. I could switch to iTunes, but that would carry the risk of ‘getting stuck’ navigating songs and thereby losing focus. Another example is sending a quick email (such as just a file that someone needs), or adding something to a todo list. The common theme for all of these are that I need to interact with some other program, but to avoid losing focus I do not want to interact with it directly.

Email a file

This is where Quicksilver really shines. With just a couple of keystrokes I can email that file to my colleague, without even seeing the mail application. It is still ‘hidden’ in another desktop, and there is no risk of me seeing that super interesting but non-urgent email lying in my inbox. Quicksilver has tons of plugins that allow me to do these quick indirect interactions with applications, which means I can recover from an interruption without losing my focus.

Pen and paper rules!

With that said however, as a final note I want to warn you not to rely to heavily on technology. Pen and paper are the base components of whatever focus-helping technique I use. Daily planning of what activities I need to do today, simple follow-up on where my time was spent, and taking notes of things to reflect upon later is best done using just pen and paper.

Further thinking led to a presentation, titled Great Developers, that I gave at the SweNUG Code Camp last summer. There I talked about what I believe a great developer to be, and how they work with code to produce a great result. I had the opportunity to do this again a couple of times during the autumn, and I also submitted the presentation for a couple of conferences during this spring.

I did however change the title, and also the abstract, since my main point in the presentation moved from ‘what is a great developer’ to ‘why are we having trouble helping good developers become great developers‘. This week I gave this presentation to 300-350 people at the JFokus 2009 conference in Stockholm, Sweden. I think it went really well, and I hope people liked it. At least one person commented afterwards:

Your presentation has been one of the most concrete, clear and to the point presentation I have heard since a long time ago, and I can mention that my motivation regarding what you have said has changed.

With the Java-people covered, I move my focus to the Microsoft TechDays conference in Västerås, Sweden on the 17th to 18th of March 2009. And if you happened to miss me on any of these occasions, there is a final chance at the Scandinavian Developers Conference in Göteborg, Sweden, on March 24th.

I hope to see you at some of these events! Take a look at the lineup of speakers for them, they promise to be great sources of inspiration and learning.

I must stress that these are my interpretations and notes of what was said, even when I refer to Jerry or anyone else.

What does experiential mean?

Wikipedia says:

Experiential learning is learning through reflection on doing [...]

In my own words, an experiential meeting (or workshop, training session etc) is a meeting that includes activities that allow you to experience something (through discussion, hands-on work, simulations or something similar) and then learn from that experience by reflecting on it. So in a sense it is about participation as opposed to just listening. But I would not describe a training session as experiential just because it includes an exercise. Without the reflection part a lot of potential for learning would be missed.

So, that brings me to the basic structure of an experiential meeting.

Exploration, Discovery, Application

Jerry described experiential meetings as having three basic components. First we Explore the topic we want to learn about, next we Discover something about it, and finally we try and find a way to Apply that knowledge. Sometimes these are used in cycles. For instance, while Applying something we learned we might move in to a new Exploration.

A style, or pattern, that I like is a session that starts with the participants exploring some concept, either individually or in small groups. They then get into larger groups (or the one group) to share their thoughts and discover patterns or key points. Next, a simulation is used where they will apply and reinforce these key points. The simulation helps the participants explore the concept further, and in the following debriefing they discover even more knowledge.

Whatever happens, happens

A basic principle of an experiential session is what Jerry described as “whatever happens, happens”. As the leader of a session, it is not your job to make sure that something specific happens, or to decide what knowledge the participants should get from it.

As a session leader you are not a trainer with knowledge to push to the participants. You are a facilitator for the learning of the group and the individuals in it. If the participants happen to take the session in a direction you had not planned for, do not automatically force them back. Of course this does not mean you should just be a bystander, or come to the session with no plan. That is not facilitating. Instead, use everything that happens to help the participants get maximum value from the session. Have a plan, and modify it as you go.

Always debrief

I guess there might be a difference for different people, but for me all the learning happens in the debriefing. Or rather, the debriefing sets my mind up for effective learning. During the debriefing I will learn a lot, but even at a later time I will realize things which I believe would have been much more difficult without the debriefing.

During the debriefing participants get to hear other participants’ perspectives. By sharing your own thoughts with others you will refine and extend your own understanding. An interesting way for the facilitator to reinforce this is to find ways to make the debriefing itself experiential. Instead of just having participants say what they thought, help them activate more parts of the brain by using alternative ways of providing feedback.

The Spectrogram activity is a good example. Ask the participants about how they feel about something. Tell them to stand up and place themselves somewhere along an imaginary line from max/agree to min/disagree. Interview people about the reason why they are standing where they are, what their context is.

As the facilitator, make sure that you ask open-ended questions of the participants. A good way to start is just asking about what they saw or heard. Move on to things that puzzled them, and next ask about insights. Finally, ask them about one thing that they can take back to work and apply. Notice the pattern? This is basically the Exploration, Discovery, Application structure again. :)

Safety and comfort

An experiential session can be very different from what many participants are used to. Make sure that everyone understands that participation in any exercise is completely optional. People can have many reasons for feeling that they do not want to be part of an exercise. For instance, Jerry told a story of someone with strong religious beliefs that would not take part in an exercise that involved playing cards. It can of course be much simpler than that, some exercises involve close contact that many people are not ok with. People who do not want to take an active part in an exercise can be given the option of being an observer for the group. They will see things that others do not, so this can benefit both themselves and the rest of the group.

When designing exercises (see more below), have safety and comfort in mind. Are the participants complete strangers to eachother, or have they been working closely together for a long time? Do not use exercises that would need paramedics to be close, or ones that single people out as “losers” (survivor-style). Giving someone a role that will make them look stupid can make them checkout of the exercise, either physically (by leaving) or mentally. Either way, it will affect their learning, and possibly the rest of the group as well.

Regarding people checking out (for different reasons), this is a strong reason (there are others as well of course) to be more than one person leading the session. Use lieutenants to help keep an eye on people. This way if a participant needs attention, the exercise can continue with the rest of the group while someone works with that person to make sure they are ok.

Designing exercises

To end with, here are a couple of tips on how to design exercises and activities for experiential sessions. To me, the most important advice is to keep the exercise itself simple, and let the learning happen in the debriefing. Think about the objective of the exercise, what do you want people to learn from it. Then think about all the steps of the exercise, all the twists it takes, and consider whether they help achieve that objective or if they distract from it. Note that I am not saying there must always be just one clear objective (the great XP game comes to mind), but that you should consider the elements of an exercise to make sure they do not distract from the objective(s).

This is also a good way to invent new exercises. An advice that was given was to try reversing the objective(s), consider how that affects the elements of the exercise, and design from there. I would recommend going further and try using all parts of a technique such as SCAMPER (not just reversal) to design new exercises with different objectives.

Finally, it can be a good idea to have backups for some exercises. Specifically if you are planning on using an exercise that takes some time, it can be necessary to have a shorter backup to use if previous parts of the session ran longer than expected.

To wrap up, in my own experience it helps a lot to include some humor and fun in the session. Try to create a positive energy, and go with that energy throughout the session. And remember, whatever happens, happens!

It is that time of the year again. Øredev, the largest software development conference in Sweden, was this week and we at Blueplane sponsored it again. This year they had a great idea. To encourage people to meet other people and actually go speak with the exhibitors, they had a game for the attendees. Each attendee had to collect a stamp from six different exhibitors to have a chance of winning some nice prizes. Not only that, by collecting those six stamps they also helped contribute money to Unicef for building schools in Africa. A great idea for a great cause!

Each exhibitor who participated in the game (by contributing money to Unicef) got to choose what they wanted attendees to do to get a stamp from them. Some just gave them a stamp when they asked for it. Boring! I wanted to maximize both our opportunity to meet people, but even more so I wanted to encourage people to talk to other attendees. So I came up with a game about collectively defining great teamwork.

To get a stamp from us at Blueplane, an attendee got one of our great looking business cards, which also doubles as a small index card. On the back side they would write a single word that defines great teamwork, according to that person.

Next, we taped the card with the word to their name badge that everyone wore around their neck, and then they had to walk around the conference looking for someone else with one of our cards with a word written on it. When they found someone (hopefully someone they had not met before) they then had to discuss and decide together which of the two words they had that were more important. Between their two words they had to assign seven points, such that the more important word perhaps got five points and the other got two points. They had to assign the points together and then come back to our booth, together, and share their thoughts and how they divided the seven points. That earned them their stamps, and we had an iPod Touch that they now had a chance of winning.

We collected the words and summed up the points they got, and then used this data to write the following definition of what great teamwork is. To everyone who helped us do this, and contributed to building schools in Africa, thank you!

Great teamwork as defined by attendees at Øredev 2008
Great teamwork builds on communication between individuals committed on a common goal. A keen interest in sharing knowledge between one another brings the team members together, creating a fun environment to work in.

I want to give credit to Tobias Mayer, who’s thoughts and description of a session he ran at Agile 2008 inspired me when I designed this game.

As I have been preparing the presentation, I have tried to identify the people will attend it. Next, to make sure that my material is relevant to these people, I have written down their reasons for being there, in a user story format. This way I can quite easily decide if an idea I want to talk about is actually relevant for the audience, or just a darling.

Here are the stories I came up with:

In order to deliver high-quality software with predictability, as a manager I want to support good developers to become great

In order to have more enjoyable challenges, work less with frustrating bugs and more with interesting problems, and advance my own skills, as a great developer I want to advance my colleagues into peers

In order to have more stimulating work and earn the respect of my colleagues, as a good developer I want to have some hands-on advice on what I can do to improve as a developer

If you want to attend the seminar on Tuesday 11 november and have a free breakfast (breakfast is served at 07.30), send an email to seminarier@blueplane.se. The place is St Gertrud Konferens, Östergatan 7b, in Malmö, Sweden. See this pdf (in Swedish) for more info.

Go check out the web site (only in Swedish) and sign up for the conference, and I will see you there!

Photo from bogenfreund’s Flickr photostream

I was recently at the Agila Sverige 2008 conference (which I guess some would call an unconference since it was made up of lightning talks and open space sessions, instead of normal 45-90 minute breakout sessions and keynotes). I presented a lightning talk version of Real Retrospectives – Not Just Talk (download pdf).

I really liked the constraint of presenting the same ideas as before, only this time I only had 10 minutes. In fact, since I am a big fan of the elevator pitch, I started by presenting my content in 45 seconds. After this I told the audience that I had now delivered my core message to them. If they thought the ideas where not that interesting or they already knew the topic, or just did not like me for any reason, they could switch to a parallel session. If not, I would spend the rest of my 10 minutes to build upon that core message and hopefully give them some more value for their time.

This got me thinking, it would be an interesting idea to have a conference start with a general session, where every speaker had to present their session in 45 seconds. This would force speakers to really think through their content and boil it down to the key ideas they want to convey, which in turn I think is a good recipe for improving the quality and consistency of the content. It would also be a lot of help to attendees who are trying to decide which sessions to attend with multiple concurrent tracks. For one thing it would of course be helpful to see what the key ideas are, but also just to see and hear the speakers in action would make the decision easier in some cases.

Photo from mag3737′s Flickr photostream

To take this idea even further, a variation could have the attendees voting for the sessions they think should be included in the schedule after getting the elevator pitches. Attendees could have an Emergency Stop button (for stopping the elevator, giving the speaker more time) to indicate that they liked the idea and would like to hear more about it by attending a full session (however long that is). This would not work for every conference of course, but it would be an interesting idea to try…

I used to have the latin phrase Docendo discimus (We learn by teaching) as my personal motto, but I think Jason Yip really nails it with:

There’s no substitute for sharing knowledge

Jason says you should always explain why, especially to children and others who really have no idea why something happens the way it does. Never just say it’s magic or so. I couldn’t agree more.

On a somewhat similar note, Paul Duvall discuss why you should “fire your best people … reward the lazy ones“. Now, the title is of course a bit misleading although there is some truth to it, but the message of the post for me can be boiled down to the following quote from the post:

If the knowledge is locked in your head, you are a less valuable, not more valuable, resource.

To me, these posts say that it is always important to take the time to share the knowledge instead of just “making it so”, whether it is something we implement in software or just something we say to someone.

The article that inspired my thought was Stan Lippman’s column entitled “Is Programming an Art?”, where he compares software development to art. I like calling software development an art, in the same way as the process of creating a Scotch Blended Whisky is often called an art (as opposed to creating malt whisky which is called a science, since it is mostly about following a protocol). When creating a blended whisky, the Master Blender will use nothing but his nose to select the combination of malt and grain whisky to include in the blend. Sometimes a blend will include up to 50 different sorts of whisky. And every batch of blended whisky that is produced must consistently taste and smell the same way. Anyone interested in Single Malts knows that whisky from different batches, even different barrels in the same batch, will have different characteristics, so being a “Noser” (which is a much cooler title than Master Blender) is truly a difficult job with no easy way of simply following a protocol.

This art of “nosing” in many ways remind me of creating software. Although many would like it to be, software development is not about following a simple process of pressing a couple of buttons and drawing some lines. Producing software requires coding, and no project is ever the same as another one.

Here’s another thought: Maybe this means we can finally retire the term Architect? Lets start using Noser instead, at least for architects doing real work. :D

* Ironically, this was right after I had listened to Don Box and Chris Sells on .NET Rocks!, talking about how no one actually reads magazines anymore and they could not remember when the last time they saw a copy of MSDN magazine was. I think that was the main reason I picked it up and browsed through it. :)

* Verify that an event subscriber really wires up a listener to an event
* Verify that an event subscriber does what it should when that event is fired
* Verify that an event publisher fires an event when it should

The first two are basically the same. If we can verify that some action that should be taken when an event is fired really does happen then we have of course also verified that the subscriber does listen to the event. But I prefer to start simple with my tests and therefore often end up with a small test like the following one for testing the wiring only:

using System;
using NUnit.Framework;

namespace TestingEvents
{
  [TestFixtureAttribute]
  public class EventsFiringTests
  {
    [Test]
    public void SubscriberWiresListenerToListenToMeEvent()
    {
      FakePublisher publisher = new FakePublisher();

      new SubscriberUnderTest(publisher);

      Assert.AreEqual(1, publisher.ListenToMeSubscriberCount);
    }
  }

  public interface Publisher
  {
    event EventHandler ListenToMe;
  }

  public class FakePublisher : Publisher
  {
    public event EventHandler ListenToMe;

    public int ListenToMeSubscriberCount
    {
      get { return ListenToMe.GetInvocationList().Length; }
    }

    public void FireListenToMe()
    {
      ListenToMe.Invoke(this, EventArgs.Empty);
    }
  }

  public class SubscriberUnderTest
  {
    private string message;

    public SubscriberUnderTest(Publisher publisher)
    {
      message = null;

      publisher.ListenToMe += IAmListening;
    }

    private void IAmListening(object sender, EventArgs args)
    {
      message = "I heard that!";
    }

    public string Message
    {
      get { return message; }
    }
  }
}

This test only tests that the subscriber actually does wire up a listener to the ListenToMe event of the publisher it is instantiated with. The next step is to verify what it does when the event is fired from the publisher. The next test takes care of that.

  [Test]
  public void MessageIsSetWhenListenToMeIsFired()
  {
    FakePublisher publisher = new FakePublisher();
    SubscriberUnderTest subscriber = new SubscriberUnderTest(publisher);

    publisher.FireListenToMe();

    Assert.AreEqual("I heard that!", subscriber.Message);
  }

That takes care of testing that a subscriber does what we expect it to when the event it subscribes to is fired. The final thing that needs to be tested is that a publisher actually fires an event when we expect it to. Lets add a new class, PublisherUnderTest, and another test.

  [Test]
  public void PublisherFiresListenToMeWhenAngry()
  {
    PublisherUnderTest publisher = new PublisherUnderTest();

    bool listenToMeWasCalled = false;
    publisher.ListenToMe += delegate { listenToMeWasCalled = true; };

    publisher.GetAngry();

    Assert.AreEqual(true, listenToMeWasCalled);
  }

  public class PublisherUnderTest : Publisher
  {
    public event EventHandler ListenToMe;

    public void GetAngry()
    {
      if (ListenToMe != null)
      {
        ListenToMe.Invoke(this, EventArgs.Empty);
      }
    }
  }

The test simply assigns an anonymous method to listen to the event from the publisher. In the anonymous method a boolean value is set to true to indicate that the event was fired.

[Test]
public void CanCreateAndShowWpfWindow()
{
  Console.WriteLine(Thread.CurrentThread.GetApartmentState());

  System.Windows.Window window = new System.Windows.Window();
  window.Show();
}

NUnit (both the GUI and console version) by default runs it’s threads in a multithreaded apartment (MTA), which can be verified by looking at the Console.Out tab. As the message says, instantiating a WPF Window requires that the calling thread is running in a single-threaded apartment (STA).

The simplest way to make this work is to configure NUnit to run tests in an STA thread. Create a config file for NUnit to use (see the docs for info on how to name it) and add the following XML configuration (or just add to your existing one):


<configuration>
  <configSections>
    <sectionGroup name="NUnit">
      <section type="System.Configuration.NameValueSectionHandler"
               name="TestRunner"></section>
    </sectionGroup>
  </configSections>

  <NUnit>
    <TestRunner>
      <add value="STA" key="ApartmentState"></add>
    </TestRunner>
  </NUnit>
</configuration>


Config updated with changes proposed in comments by JohnD. Thanks!

This tells NUnit to run all tests in STA threads. However, if you just want a single test (or some but not all) to run in STA (or MTA, if you have used the above configuration to set the default to STA) you have to resort to code. You need to start a new thread and set the apartment state you want, and then run your unit test in that thread. I used CrossThreadTestRunner (from Peter Provost) and just added support to choose which apartment state to create and run a thread in. The following code example shows how to use it:

[Test]
public void CanCreateAndShowWpfWindow()
{
  CrossThreadTestRunner runner = new CrossThreadTestRunner();
  runner.RunInSTA(
    delegate
    {
      Console.WriteLine(Thread.CurrentThread.GetApartmentState());

      System.Windows.Window window = new System.Windows.Window();
      window.Show();
    });
}

My modified CrossThreadTestRunner class looks like this:

using System;
using System.Reflection;
using System.Security.Permissions;
using System.Threading;

namespace UnitTestThreadApartmentState
{
  public class CrossThreadTestRunner
  {
    private Exception lastException;

    public void RunInMTA(ThreadStart userDelegate)
    {
      Run(userDelegate, ApartmentState.MTA);
    }

    public void RunInSTA(ThreadStart userDelegate)
    {
      Run(userDelegate, ApartmentState.STA);
    }

    private void Run(ThreadStart userDelegate, ApartmentState apartmentState)
    {
      lastException = null;

      Thread thread = new Thread(
        delegate()
        {
          try
          {
            userDelegate.Invoke();
          }
          catch (Exception e)
          {
            lastException = e;
          }
        });
      thread.SetApartmentState(apartmentState);

      thread.Start();
      thread.Join();

      if (ExceptionWasThrown())
        ThrowExceptionPreservingStack(lastException);
    }

    private bool ExceptionWasThrown()
    {
      return lastException != null;
    }

    [ReflectionPermission(SecurityAction.Demand)]
    private static void ThrowExceptionPreservingStack(Exception exception)
    {
      FieldInfo remoteStackTraceString = typeof(Exception).GetField(
        "_remoteStackTraceString",
        BindingFlags.Instance | BindingFlags.NonPublic);
      remoteStackTraceString.SetValue(exception, exception.StackTrace + Environment.NewLine);
      throw exception;
    }
  }
}

A final note: As opposed to NUnit, both TestDriven.Net and Resharper’s Unit Test Runner run tests in STA threads. I got bitten by this recently when all the tests where green on my machine, but when I committed the build server went red on me. I was using Resharper to run the tests, while NUnit-Console was used on the server. Hope this might help someone else in the same situation.

While I can hope that this might change (as said by others, some IDE competition would be great) I am afraid that it will not happen anytime soon. So what can we do in the meantime? I think it is important for those of us who are using OSS tools (or simply tools from other vendors) to promote them in the .NET community. I am not saying that there always exists a better alternative to Microsoft products, often there does not, but it is important that we help the rest of the community see and evaluate the alternatives. I think some good work is being done here. At öredev, the largest developer conference in Sweden, the .NET track consisted of ten seminars and two half-day workshops. Half of these (one workshop and five seminars) discussed some new technology from Microsoft (Atlas, .NET 3.0, Linq etc), but half of them where mostly about educating the .NET community about professional development using TDD, domain-driven design and AOP. These are competencies that are much more common and standard knowledge in the Java community than what they are in .NET.

At the latest SNUG meeting I did my presentation on testable user interface code and Joel Fjordén and Richard Houltz discussed tools for developer productivity (CodeRush/Refactor and Resharper was also mentioned), coding guidelines (from outside of Microsoft, sort of) and how to enforce them using Joel’s CodeStyleEnforcer plugin. This is what we need to do, getting the .NET community together at meetings and facilitating discussions about professional development and creating better code, by showing what tools are available. This of course includes Microsoft tools, but we should not be limited to this one major vendor.

I started out by showing a demo application, built in the all too common way of simply having all code in one form. Naturally, this was only an example so a real application would have multiple forms and maybe even reusable code in the form of some custom user controls. The problems with this application is that it is difficult to test the behaviour of it. Automating some sort of user interface driver to test it creates tests that are much too brittle and difficult to maintain (there are even those that take a screenshot of the UI and then compare the screenshots created by a test to the “correct” ones!).

I then showed how to take the first step to a better design, by separating the domain logic from the UI class. To my surprise only about half of the audience raised their hands when I asked how many do this in their applications. I guess that it might be that some just did not bother to raise their hands, while others did not really associate with the example I showed (maybe they are using a “Transaction Script”:http://www.martinfowler.com/eaaCatalog/transactionScript.html style rather than the “Domain Model”:http://www.martinfowler.com/eaaCatalog/domainModel.html I showed). This step is what Martin Fowler describes as “Separated Presentation”:http://www.martinfowler.com/eaaDev/SeparatedPresentation.html. My examples are very similar to the ones in Fowler’s texts, so it should be very easy to read his detailed writings and take a look at the examples I created to get a good understanding of the things I discussed in the presentation.

The next step I discussed is to move presentation logic from the UI class to a separate class, often called a presenter. The UI class will simply delegate user input to the presenter class, so I think a simple name for this pattern would be Delegated Input Handling (or similar), although I have never heard it called something like that. The common name for this is of course Model-View-Presenter, but I tried to avoid discussing Model-View-Presenter and Model-View-Controller until later in the talk. The demo (in my code) is called “Passive View”:http://www.martinfowler.com/eaaDev/PassiveScreen.html, since the view (the UI class) contains no logic at all. The view does not do anything else than signalling the presenter when user interaction happens (delegated input handling) and then acts as a getter/setter for the various UI elements that the presenter needs to control.

After this I showed a variation of the step above, where the presenter was simplified by replacing the simple plumbing logic with data binding. To accomplish this the presenter exposes the model (domain objects) to the view so that the view can bind the UI elements to properties of the model. The reasoning for doing this is that data binding is “automatic” and included in the framework, so we can safely use it even though we can no longer test this part of the presentation logic. Martin Fowler calls this pattern “Supervising Controller”:http://www.martinfowler.com/eaaDev/SupervisingPresenter.html (though I would call it Supervising Presenter as he discusses in the article), since the presenter now only supervise things by reacting to user input and letting the view automatically show the current state of the model. However, as a supervisor the presenter will also take control of those situations where automatic handling such as data binding is too difficult or impossible. In those situations it will work with the view in the same way as in Passive View. My demo has an example of this.

Finally, I showed a demo of “Presentation Model”:http://www.martinfowler.com/eaaDev/PresentationModel.html. This pattern is kind of similar in intention to MVP (Passive View and Supervising Controller), but it is differently realized. Here instead of having a presenter we create a separate class, PresentationModel, to hold the current state of the UI. The UI class then does nothing but delegate input handling to the presentation model, and synchronize it’s UI elements with the current state exposed by the presentation model. One of the good things about this is that unit tests become easier to write, since there is no need to fake out the view and test the interaction between the view and the presentation model. With the presentation model completely unaware of the view it is also easy to create the presentation logic (in the presentation model) without any view at all while testing.

Some other relevant links that where in some way mentioned in my talk are listed below.

* “Active Record”:http://castleproject.org/activerecord/index.html is a productive way of setting up a data access layer.
* “MonoRail”:http://castleproject.org/monorail/index.html is an MVC-based web framework for the .NET platform.
* Finally, I mentioned the “Agile öresund”:http://mawi.org/agileoresund/ user group that “Marcus Widerberg”:http://mawi.org/ and I are starting up with some others. If you are interested in meeting quite informally to discuss agile topics, please take a look at the wiki.
* And if you missed it in the text above, you can download the demos and presentation I gave in a zipped file.

On behalf of myself and “SNUG”:http://www.snug.se/, I want to thank those who attended the meeting an hope to see you again at the next meeting which will be in February.

One such problem that I just had was working with a RichTextBox. The application should contain a text box where the users can enter text, using all the standard functionality such as bold, italics etc, and this information (text and markup) should be stored in the database. This was not as straightforward as it used to be in .Net 2.0 (or earlier). Since I guess other people will likely want to do the same thing I am posting the code I wrote to do this.

public string InputText
{
  get
  {
    string text = "";

    using(Stream stream = new MemoryStream())
    {
      TextRange contents = new TextRange(
        textBoxInputText.Document.ContentStart,
        textBoxInputText.Document.ContentEnd);

      contents.Save(stream, DataFormats.Xaml);

      stream.Position = 0;

      using(StreamReader reader = new StreamReader(stream))
      {
        text = reader.ReadToEnd();
      }
    }

    return text;
  }
  set
  {
    textBoxInputText.Document.Blocks.Clear();

    if(value != null && value.Length > 0)
    {
      using(Stream stream = new MemoryStream(
        UTF8Encoding.Default.GetBytes(value)))
      {
        TextRange contents = new TextRange(
              textBoxInputText.Document.ContentStart,
              textBoxInputText.Document.ContentEnd);

        contents.Load(stream, DataFormats.Xaml);
      }
    }
  }
}

The property InputText is part of the view interface for this page in our Model-View-Presenter architecture. The presenter uses this property to show/collect the value in the model.