Update on 6/28 – I did a Thirsty Developer interview with Doc List, about Open Spaces and the unmeeting that we held.  Check out the Episode Page or Listen to the show.  I also made a minor change to the text below (moved one of the titles down a paragraph).

I think pretty much everyone has heard of the concept of the Open Spaces (or its close cousin the unconference) Open Spaces are:

A facilitated participant-driven face-to-face conference around a theme or purpose. (according to the unconference blog) 

Recently some of my teammates gathered together to talk about planning our direction for the next year (the Microsoft fiscal year runs from July to June).  We had a day together and a lot of items to cover, as you can imagine planning the direction for a large team for a full year will give you a lot to talk about. 

I got the task of putting together the agenda, which is a tough when you have limited time and lots of material.  Brian Prince, my friend and colleague from Ohio, put out the suggestion that we should try to apply the Open Spaces Technology to our planning meeting.  Our boss, Brian Moore, is always willing to let us try things that are unconventional (with a few caveats that I will mention later).  So eight of us set about having a meeting that used some of the Open Spaces principals or what I am dubbing an unmeeting.

Applying the Open Spaces Principles

With open spaces, there are 4 principles that guide the event.  They are very Zen like, which is why you generally have a professional facilitator to help guide you through the application of the principles.  The principles are:

1. Whoever comes is the right people
2. Whatever happens is the only thing that could have
3. Whenever it starts is the right time
4. When it's over, it's over

I got to serve in the role of facilitator for our “unmeeting”.  We did a number of things to apply the Zen like principles.  Our plan was to have 6 attendees at the event, but we discovered that we needed more “right people” there.  So we recruited a couple more people (including one that we picked up at a happy hour the night before).

The majority of our agenda was driven by a combination voting / consensus process (we used post in notes on the whiteboard with tick marks).  We also modified the conversation throughout the day, which was important because there were a couple of topics that did not fit into nice hour long segments.  And of course was not problem with everyone knowing that the meeting was over, after a long day of planning, it was obvious it was over. 

In addition to the 4 principles of Open Spaces, there is one law…..

Another key difference between the unmeeting that we held and the traditional Open Spaces is that the “Law of two feet” was somewhat modified for our purposes.  The law of two feet can be summed up as:

If at any time during our time together you find yourself in any situation where you are neither learning nor contributing, use your two feet. Go to some other place where you may learn and contribute.

No voting with your feet at our unmeeting

The law of two feet is great when you have choices of the activities to participate in; many Open Spaces events will have multiple sessions going on at the same time.  If you are not getting something out of your current session, it is great to be able to leave without you or the other people feeling awkward.

Our unmeeting did not have breakouts, so the only option was to leave the room for a while (which we encouraged if you needed a mental or physical break) or to lose focus on the proceedings by getting lost in your e-mail.  We tried to discourage non-topical use of your laptop during our proceedings (I as the facilitator used some creative techniques as you can see from the photo).  This was somewhat a violation of the law of two feet, but part of this was driven by our culture as a company. 

Most of you have probably never been to an internal Microsoft meeting (unless you work there).  The great majority of the meeting has the Microsoft folks all affixed to their laptop screens dealing with the avalanche of e-mail we get on a daily basis (we try to behave ourselves better when we are at a meeting with customers and partners).

The boss is still the boss

One of the things that was different about our unmeeting was that it was commissioned by our boss and he did have a specific set of outcomes that he needed to accomplish at the conclusion of the meeting.  As a result, he did dictate that we cover a few agenda items. 

If it was a true Open Spaces, the participants could have chosen to ignore topics that they did not want to cover, but this was an unmeeting.  We accommodated the “mandatory” sessions by putting them on a different colored sticky from the other topics during the voting/consensus process.  The participants still got to choose when in the agenda that we covered the mandatory sessions, but we had to work them into the day.  Other than that, our boss did not really rule the meeting with an iron fist (despite the picture).  He did serve in the role of the “expert” as we would have questions about the outcomes that we were trying to accomplish.

Overall I think we had a positive experience applying the Open Spaces Technology to an internal meeting.  I would encourage considering how you could apply the principles and law at your work.

At the Chicago Code Camp this last month (May 30th) I got to see a great presentation by Micah Martin (@slagyr) entitled “Ruby Kata and Sparring”.  Micah’s presentation was in a very “Zen” style and the majority of his talk was about the importance of practicing your coding skills.  He talked about how we can learn from two common types of training that are used in the various martial arts:

Kata - detailed choreographed patterns of movements practiced either solo or in pairs…most commonly known for the presence in the martial arts

Sparring - relatively 'free-form' fighting, with enough rules, customs, or agreements to make injuries unlikely

After he introduced the concept of Kata, he showed us a demonstration using a well known exercise called Langston’s Ant.  Micah bowed to the audience (as is typical in Kata) and proceeded to  “live code” his implementation from scratch and ended with another bow to the audience (also typical).  The Langston’s Ant has no perfect solution, so he then asked the audience to rate his code and to give him feedback on how to improve his implementation.

One of the things that struck me was how Micah answered the question “It seems like you are very practiced in writing this solution, how many times have you done this?”.  Micah told us that he had done the solution more than 50 times.  He did point out that he had not done the same implementation 50 times (as if he were practicing giving a Langston’s Ant demonstration), but had evolved his implementation over the course of his Kata sessions.  His 50th solution was “better” than the first solution as he had refined it; just like your technique should get better as you practice your martial arts.

I personally need to get a coding workout.  I am an evangelist for Microsoft, but that actually involves a lot less coding time than most people would think (the amount of time varies from individual to individual, some of my colleagues code a lot more than others).  A field evangelist for Microsoft is typically a technology generalist, having to cover a real breadth of technologies.  As you may know, Microsoft has a lot of technologies, so we spend a fair amount of time immersed in learning new things and not necessarily practicing our coding skills.

Over the course of the summer, I intend to get a coding workout; knock the rust off or sharpen the saw as it were.  I am going to practice a coding exercise every week (unless I take a week off for vacation; which I would totally unplug for).  To keep myself honest, I am going to post something about each workout up on the blog, even if it is to admit a FAIL.  Look for the first post next week: Coding Workout: A twitter badge using jQuery.

Note: I have been on an un-planned blogging hiatus for the last 2+ months.  It is not that I have not had things I have wanted to say, but have just been short of time to say them.  For those of you who have stuck around (kept me in your RSS reader or checked the site for updates), I thank you for your patience. I did want to write a “Sorry for not blogging” post (I hate those – just start blogging!).

This past weekend I took a flight and I did something that I normally do not do, which is pay attention to the flight crew as they give their safety briefing.  Years of air travel have given me the ability to recite the standard briefing in my sleep, so normally I read a book.  One of the first things they tell you in their safety briefing is to get out the briefing card and follow along, since I was paying attention this time, I decided to play along.  As I looked at the briefing card, I was struck by how much information that they could fit into such a compact space and with so few words, because they leveraged the pictorial so well.  Here is a quick glimpse of one of the pictures that gives the complete procedure for opening up the emergency exits and getting out of the plane:

Image from Aero Safety Graphics

I have been really interested in the concept of pictures as better documentation than words for a while.  I think my fascination was first spurred on by Mike Rhode’s sketchnotes.  I even asked Mike about it in the Thirsty Developer Podcast Dave and I did with him last fall.  I was specifically asking about pictures, graphics and typography in the design stage at the time, but I think the concept applies equally well (if not better) to the finished product.  It is a great way to show the business process that a software application can support.

Furniture Instructions

Multi-lingual by default?

In addition to capturing lots of information in a small space, pictures done in a certain style have the advantage of being multi-lingual by default.  Take the instructions that I got with the some assembly required furniture pictured here.  The instructions are able to tell me a lot without using any words, and thus does not need to go through the long, tedious and expensive process of being translated to multiple languages.  A real cost saving move if the product is being sold in different countries.  This particular instruction manual only had one page with writing on it that needed to be translated.  That one page was translated into 8 different languages, so clearly that was the intent of the designers to go global with the single document.

Not for every situation

Clearly there are times when pictorial based instructions could be overkill for a situation.  I can think that the contrast to “A picture is worth a thousand word” could be “Eight words is quick than a 1/2 dozen pictures”.  I do think there are situations were pictures could really enhance documentation, so maybe we can learn a thing or two by paying attention to airline safety briefings.

As I mentioned previously, I spoke to the Architecture Special Interest Group (SIG) of the Indianapolis .NET Developer Association (IndyNDA).  Steve Porter, who is in charge of the group, asked me to present when they founded the group last September and it took a few months for our schedules to align and I am glad that they did.  Steve asked me to do the “in person” version of my Architecture by Baseball series of articles.

I have to admit at first I did not see the value in standing up in front of a group and covering things that I had already written.  As I was putting the presentation together, however, I realized that there are a lot of things that I had not covered in the articles themselves add a lot of color to the topics presented in the written form.  I had a lot of fun putting the talk together (which I did at the last minute, the night before) and had even more fun delivering the talk to the group (about 35 people or so).    Thanks to Steve and to all those who attended the talk.

I promised I would make the deck available to the people there and thought I would share it here as well.  It is up on My Slideshare Account:

Last week I had the pleasure of speaking to the Architecture Special Interest Group (SIG) of the Indianapolis .NET Developer Association (IndyNDA).  Special thanks to Steve Porter, who is in charge of the group, for allowing me to speak.  One of the items came up was the question (asked a couple of different ways) “how do you keep up with new technology?”  I answered (in a couple of different ways) that long ago I gave up trying to keep with up all technologies; it is impossible to even keep up with Microsoft .NET technologies, let alone all Microsoft technologies or the greater technology picture. 

I did mention that I listened to quite a few podcasts.  Given the time I spend in the car and at the gym, it is a great was to keep your pulse on what is new and interesting.  I was asked for my list of podcasts that I listen to regularly, so I thought I would list them here for you.  One thing to note this is all the podcasts that I subscribe to, not just technology podcasts (I think that it is important to have a diversity of knowledge).  Also I will listen to specific episodes of other podcasts, especially when people point out good episodes to me.

Baseball History Podcast – If you follow my writings, you will pick up on the fact that I am a big baseball fan.  I am also an avid history buff, so this podcast is a perfect combination of two things that I really enjoy.  It is a weekly show by Bob Wright, and this show actually inspired me to start my own podcast.  In addition to the great baseball information, Bob occasionally shares information on podcasting.

StackOverflow podcast – StackOverflow.com is a great question and answer programming site put together by Jeff Atwood and Joel Spolsky.  One of the neatest things about it is that if you listen to the podcast, you get some great insights into how the site was created and if you have listened to the podcast from the very beginning (episode 1), then you really have deep intimate knowledge of the site.  I have always wanted to create a “from scratch” startup company like Joel and Jeff are doing (although Joel still has his day job).

Diggnation – This is a weekly look at some of the top stories from the site digg.com that is co-hosted by the founder of digg.  The show is not just about technology, but many of the stories that you see on digg are technology related, so you get quite a bit of what is new by listening to the show.  The show is quit hilarious.

I, Cringley – This podcast is actually the spoken word edition of the blog of Robert X. Cringley, the former technology columnist for PBS.  He left PBS in December of 2008 to run a startup company and moved his column to his own site.  Because he was a technology columnist for PBS for many years (and with InfoWorld prior to that), most of his columns are technology related although he will get into the current affairs quite a bit (economy, stimulus plans, housing market, etc).

NPR Story of the Day – This is a daily show from National Public Radio in the United States.  They cover one story in the podcast each day and the length of the story varies widely from ~3 minutes to full feature episodes that can last closer to 20 minutes.  Sometimes it is stories that you will see on other new channels, but sometimes it is a story that you would not have heard somewhere else.

Security Now – This show is part of the TWIT network of shows (run by Leo Laporte).  It is a weekly look at Security related issues with Steve Gibson, an independent software developer.  They cover security news, but they spend a lot of time talking about deep security topics like explaining how SSL works.

Onion Radio News – This show is purely for fun.  The Onion is a satirical newspaper (and website) and this is their audio version.  They have a ~1 minute newscast everyday that is a total joke (don’t confuse it with a real news story), and usually it is quite funny.

Thirsty Developer – This is a shameless plug for the podcast that I co-host with Dave Bost.  But I do subscribe to the show (mainly to QA the RSS feed, because I listen to the show while editing it), so it is a valid part of the list.  Every week we interview a real world developer, designer or architect and talk about something they have done with a technology.  We will interview “big name” guests on occasion, but we don’t limit ourselves to “conference circuit” of speakers that you see on every other podcast; we like to talk to the normal folks.  As a result the show may not be as polished at times, but I think that is part of the charm.  Recording and producing the show is the most fun I have in my job (although it is not an official part of my job at Microsoft).

Windows Weekly – This is another TWIT network show that is a weekly look at all things Microsoft (so much more than just the Windows Operating System).  Most of the shows are just Leo Laporte interviewing Paul Thurrott, but on occasion they will have a guest on the show.  Paul Thurrott is a journalist and a blogger (http://www.winsupersite.com/) that is very plugged into Microsoft.

I am sure that I am missing a great podcast (or two).  If you have a suggestion for one that I might not have stumbled upon, please drop me a comment below.  Thanks!

This is the eleventh in a series of articles about how we can learn about software architecture by studying and comparing it to the sport of Baseball.  This series was inspired by the book Management by Baseball.

As a baseball fan, some of the sweetest words that you can hear are “Pitchers and Catchers report today”.  The pitchers and catchers are the first players to report to Spring Training, so when you hear that you know that baseball is on its way.  Spring Training is a chance for the players to get back into shape for the season.  It is also a time when young players get a chance to “make the big team”.  Managers will also use Spring Training to try players at a new position, make changes in the batting order and integrate new players into the team.  Spring Training also involves exhibition games that give the players a chance to experience game play before the official season starts.

The benefits of Spring Training for a baseball team can be lumped into one of three categories:

• Getting back into “game shape”
• Learning new skills / positions
• Jelling together as a team

Spring Training for architects and developers

Typical software development projects usually have a ramp up period before the project is at full stride.  As a matter of fact I cannot recall any project that I have ever been on that did not have a quite protracted period of less than full productivity.  Requirements are still being gathered, environments (servers and desktops) are still being configured, software is still being procured, etc.  This can be quite a frustrating time for the developers, but especially the architects on the project.  You don’t have enough of the facts to design and build the real business application, but the clock is ticking on the project so the need to get started is pressing upon you.  I propose that you use the time to do some Spring Training.  The software development team should spend some time focusing on the same type of activities that you see listed above.

Get back into “game shape” – If you are starting a new release of an application chances are that you spent your past few week not writing new code, but stabilizing the previous release for shipment or doing post deployment activities.  The “new code” muscle has probably not been stretched out for a few weeks.  Practice writing new code from scratch, even if you don’t know if it will be used in the application.  Get those skills sharpened up so that when the rest of the project comes together you will be ready.  Don’t do this in the “prototype” throw away fashion, you may throw away the code in the end, but don’t write it as throw away code.  Write real code with unit tests, error handling, documentation, etc. 

Learning new skills / positions – If you are working on a new application or if you are new to the application there is a good chance that you will be working with unfamiliar technology.  You may be a fantastic ASP.NET Developer, but this may be your first project with ASP.NET MVC Framework.  Use this time to become familiar with the new technologies.  It also may not even be a new technology, but rather a new style or technique that you are applying.  Use the projects Spring Training time to become really familiar with the new stuff.

Jell as a team – Like baseball, software architecture and development is a team sport.  You have to be effective as a team in order to succeed.  Use the Spring Training time to get to know the new team members (if there are any) and to get accustomed to working well together.  As a quick aside you should be open to ideas that new players bring to the team, you should always be open to hearing best practices.

I have talked with several customers recently about the benefits of using Continuous Integration (CI) practices as part of your development process.  I am a big believer in continuous integration as I have seen the software quality greatly increase on several projects that have implemented the practices.  The only thing that I have seen increase the quality more is a good base of unit tests and the good base of units tests is pretty much a prerequisite for CI (you can do CI without unit tests, but you are not realizing a fraction of the benefits).

One of the key benefits of CI is that it makes everyone pay attention to the build as a vital part of the process.  When the build is done by a dedicated person, the Build Master as they are sometimes called, you don’t get that sense of ownership. When the team I was on first implemented CI, we wanted to create the sense of ownership in every person on the team.  We also wanted people to take the build seriously, even if it was just an interim CI build.  We also wanted to have a little fun with it, so we bought a plunger. 

We had a very simple team rule: anyone who broke the build would have to have the plunger visible on their desk from the time that they broke the build until the next person broke the build.  There was a bit of shame involved in this, but it was meant to make you more aware before you committed code into the system.  At first we noticed the plunger moving around quite a bit.  As time went the team started following better practices: getting the latest version more frequently, adding additional unit tests and running the build locally before committing source.  The plunger moved less frequently which also motivated the team to increase their quality, because if you broke the build you knew you were going to have the plunger for a while.

These were the obvious benefits that you would expect from people paying attention to the build.  The unobvious benefit was how much more aware that the developers on the team became of the dependencies on each other’s work.  You might commit a change and it work fine, but a corresponding change in another developers code could cause the build to fail later (our plunger rule involved root cause analysis and you could inherit the plunger after the fact even if your change did not break the build right away).  This increased the communication among the developers on the team, which almost always increases quality.

So you want to increase your code quality, one of the best investments you can make is a $3.00 plunger.  And please, don’t try and save a few bucks by grabbing one out of the janitor’s closet.  :-)

Kiosk Keyboard

I visited the Chicago Auto Show this past weekend and got to see a lot of neat displays of current and upcoming vehicles.  I have gone to auto shows on and off for the past few years and one of the real trends that I have noticed is that the displays that accompany the vehicles themselves have gotten more and more interactive.  In years past you would get to see 10-15 cars from a manufacturer and then would would get one or more brochures to take with you.  The displays of the cars themselves are much more interactive with vehicles that are partially taken apart or turned on their side (so you can see the undercarriage).  There are also a lot of computer based kiosks that you can interact with (to compare models, etc). 

I took the above photo of one of the keyboards that was built into an interactive display (there were several similar kiosks with keyboards like this on the show floor with only minor differences).  You can see that this is not your typical off the shelf keyboard that ships with your desktop machine or that you pick up at your local computer store.  The profile of the keys and the overall keyboard is one of the obvious things.  The hardware is specifically designed to be touched, pounded on and man-handled by the thousands of people that will use the kiosk during the course of the auto show.  I did not test it out but I bet the keyboard it sealed in such a way that if you spilled a drink on the keyboard it would not break the unit; you may need to wipe it up or your fingers will get sticky :-).  Clearly the company that created this display did their homework about the type of abuse that the hardware would take.

Do you observe your software in the field?

There is a lesson that we can take away from observing the kiosk systems that are designed to be used at high traffic trade shows: we need to see our applications in action before we can fully appreciate the full user experience.  This does not only apply to high traffic situations like the trade show kiosks, but it applies to software being used in all situations. 

I see this when I visit my local bank and see the tellers struggle to use the mouse on their narrow workspace (I think that these particular teller windows were built before PCs were common).  If the software developer spent some time observing the application in practice they might build in better keyboard support to the application, or at least recommend purchasing a trackball that would be easier to use in a confined space.

Even if you are developing web applications you can learn a lot about the use of the application by watching someone use it in action.  Simple observation might give you great clues to issues with your software: 

• Do they use they menus that you provide? 
• Do they “deep link” bookmarks/favorites/shortcuts in your application in a way that you did not expect?
• Are they running in a much smaller or larger resolution than you are testing for?

Obviously if your application is broad reaching, you are not going to be able to see even a small percentage of your population using your application, but even seeing a couple of typical users will give you great insight into things that you can improve in your application.

I have been giving a lot of thought to interoperability lately (I wrote a little bit on it a couple of weeks ago in Trains and Interoperability).  As an industry, we spend quite a bit of effort on having dissimilar (and even similar) computer systems communicate with each other in an easy and safe manner.  We have spent a lot of time just getting the systems to communicate with each other “on the wire” and we have made great progress in the last 10 years on getting systems to just talk to each other (Web Service standards have made synchronous calls across platforms almost a non-issue). 

We have not made as much progress on the data formats that these systems use to communicate.  With a few exceptions, there are not really any universally accepted standards.  A codified system to provide data formats is one of the things that Microformats provides.  For this reason and because they are so easy to adopt, Microformats are and important web standard that we should pay attention to.

Microformat – the example

The easiest way to explain Microformats is to show them in action.  The classic example of a microformat is the contact card (or hCard) which lets you tell people how to contact you.  I used a plug-in for Windows Live Writer to create my card and it is shown here:

Microformat – the mark-up

So at this point you may be saying “Big deal, it looks like just HTML”.  The difference between this and just plain old HTML is that it is marked up with specific tags that are defined by the standard.  The markup is done with specific CSS classes (which are an extensible standard) as opposed to using HTML to mark it up.  If you do a “view source” on your code you will see <div> and <span> tags that are match the names in the specification.

          <
          div 
          class
          ="vcard">
<
          span 
          class
          ="fn
n"> <
          span 
          class
          ="given-name">Larry</span>
<span class="given-family">Clarkin</span>
</span>
<div class="org">Microsoft</div>
<div> <a class="email" href="mailto:blog@eraserandcrowbar.com">blog@eraserandcrowbar.com</a>
</div>
<div> <a class="url" href="http://eraserandcrowbar.com">http://eraserandcrowbar.com</a>
</div>
</div>

One of the best benefits of using CSS for the markup is that it degrades “nicely” on older browsers and it does not have to affect the layout of the page.

Microformats – the viewers

The real magic of the CSS / microformat is twofold.  Now that the page is marked up with the microformats, a program that is looking for contacts can easily find them on the pages, as opposed to having to do a lot of complicated parsing and having meta-data about the site.  That is the machine to machine type of interaction.

For human to machine interaction, you can add an extension (or add-in) to your browser that understands microformats and it will “light up” the experience in the presence of a known microformat.  This is a screen shot of upcoming.org (an events site) with an Internet Explorer extension from the oomph toolkit; recently released by Microsoft (it contains several goodies for microformat development).  The extension found 74 upcoming events on the page and will allow you to scroll through them and add them to your calendar with the click of a button (6 different calendars types are supported).

The event (or calendar) microformat is called an hCalendar.  One of the neatest things about microformats is that they are building out a taxonomy of items that you can tag up (events and contacts are just the first formats and most supported ones).  You can see a list of the ones “in the works” on the Microformats wiki.

Note: Microformats were featured on a recent episode of the Thirsty Developer Podcast.  I sat down with Pete Prodoehl who was the first person I ever heard mention Microformats.  Give the show a listen if you want a casual conversation on why they are important.

Social network fatigue - n. The ennui induced by persistent solicitations to join new social networks. It is especially acute in those who are already members of more MySpaces than they can remember. (from the Wired Jargon Watch)

I have gotten at least a dozen people asking me (via e-mail, SMS or in person) questions about why I am not on Twitter any more.  Last week one person was very concerned because not only was I not on Twitter, but the Thirsty Developer Podcast website that I co-manage with Dave Bost was down (we had a problem with a configuration change that was made by the ISP this past Monday).  So I wanted to let everyone know that everything is okay, I left Twitter and Facebook by choice in early December.  I left both of these very popular social network sites, because I was very distracted by using them and quite frankly I was feeling a lot of fatigue in keeping up with them.

Twitter Pack
By Carrot Creative
Used Under Creative Commons

Addicted or distracted?

I hear a lot of people say that they are “addicted to Twitter” and I did a quick search and found that thousands upon thousands of people have written that very phrase on blogs, articles and on twitter itself.  I don’t think I was addicted to twitter (or any social network), but I did find it distracting me from things that I feel are more important.  I had over 300 followers and I was following over 300 people at my peak on twitter (I followed the karmic rule that if a real person followed me, I would follow them back).  When I looked at the timeline, it was very easy to get lost in conversations flowing back and forth.  I found that every time I opened a twitter client I would spend 1-15 minutes browsing the feed.  This usually happened when I had much better things to do.

The final straw

In early December I got a tweet from someone who (politely) pointed out to me that I had not updated my blog in over a month (it was actually closer to 6 weeks).  I really enjoy blogging and I was really disappointed in myself that I had gone that long without posting an article.  So I decided to take the time that I spent on twittering and facebooking (is that a word?) and channel it into more consistent blogging.