Live Writer Test Post

Microsoft just released a technical preview of the newest version of Windows Live Writer.  Since this has a couple of features I’ve really been looking for, I’m going to try it out.  If it works well, I’ll start using it for all my (very infrequent) posts.  I apologize in advance for all the random content – I just want to try out the new features to make sure they work how I want them to.

Here’s a picture:

 

Here’s a table:

Heading 1	Heading 2
Row 1 Column 1	Row 1 Column 2

Here’s a map (our old house in Tucson):

Here is a video:

Emily's Birthday

Here is a code snippet:

   1: using System;

   2: using System.Collections;

   3: using System.Reflection;

   4:  

   5: namespace ExternalDSL {

   6:   public class DslExecuter {

   7:     private readonly Hashtable parameters = new Hashtable(StringComparer.InvariantCultureIgnoreCase);

   8:  

   9:     public void AddParameter(string name, object parameter) {

  10:       parameters[name] = parameter;

  11:     }

  12:  

  13:     public object Invoke(ActionExpression expression) {

  14:       object obj = parameters[expression.Left];

  15:       if (obj == null)

  16:         throw new InvalidOperationException("Could not find parameter with name: " + expression.Left);

  17:       MethodInfo method =

  18:         obj.GetType().GetMethod(expression.Operator,

  19:                                 BindingFlags.IgnoreCase | BindingFlags.Instance | BindingFlags.Public);

  20:       if (method == null)

  21:         throw new InvalidOperationException("Could not find method operator " + expression.Operator + " on " +

  22:                                             expression.Left);

  23:       ParameterInfo[] methodParams = method.GetParameters();

  24:       if (methodParams.Length != 1)

  25:         throw new InvalidOperationException(expression.Operator + " should accept a single parameter");

  26:       object converted;

  27:       Type paramType = methodParams[0].ParameterType;

  28:       if (paramType.IsEnum)

  29:         converted = Enum.Parse(paramType, expression.Right, true);

  30:       else

  31:         converted = Convert.ChangeType(expression.Right, paramType);

  32:       return method.Invoke(obj, new object[] {converted});

  33:     }

  34:   }

  35: }

The Immense Value of Failure

A number of years back, I had the (dis)pleasure of developing software that had to interface with systems managed by a remote team that was paralyzed by the fear of failure. There was so much fear over making any wrong decision, that failure was guaranteed. The desire to “not be wrong” drove intense “Big Design Up Front” (BDUF) discussions and over-large meetings to “build consensus” and “get buy-in” that slowed progress to a crawl on good days, and moved the project backwards on the (frequent) bad days. It made even trivial decisions painful. This delayed the project to the point that it was eventually cancelled. The desire to not fail had let to failure.

I can see two root causes for this problem:

1. A Dysfunctional Work Environment: Anyplace fear is a major behavior-inducing factor.
2. An Incorrect View Of Mistakes: A belief that being making any wrong decision will cause permanent harm.

I’m only going to talk about #2 today – I’ve had several thoughts about this subject. #1 would be a topic for another article, but it’s not what I’m interested in right now. My premise is that just about every “good” thing we have in the world today came about because of a whole bunch of mistakes. For every system we have that works well, there are a nearly infinite number of them that failed for some reason, and which led the next person/team to try something slightly better. This failure (aka progress) is extremely valuable. This insight leads to two points:

1. No real discoveries were ever made without significant effort and trials. Edison with the light bulb. Newton with the laws of motion. Einstein with the general theory of relativity. There was a great show on PBS a long time ago called “The Ring of Truth” hosted by Phillip Morrison that went into great detail on this historically recurring theme.
2. A “good” mistake is small enough and made quickly enough that fixing it is not difficult and it teaches about the problem.

An often used analogy for project development is driving. When I get in the car, I usually know pretty much where I want to go. I don’t know what traffic will be like, so I’ll have to adjust for it along the way. I also don’t know if I’ll have to adjust for road construction, weather conditions, a flat tire, etc. All of those things get fed into the course corrections I make as I’m MOVING towards my destination. I could spend a long time working out a plan for each of these contingencies before I left, but even if I did, there are certainly things I would have forgotten, and would still have to adjust to. I’m not advocating doing NO planning beforehand, but doing “just enough and no more”. Of course the amount of planning should vary in direct proportion to the uncertainty of the terrain, and the size of the trip.

So, getting back to a project perspective, my belief is that every team should use the following loop:

• Iterate
• Fail Early
• Fail Often
• Learn From Small Successes & Save Them
• Be willing to say “I Don’t Know”, but be willing to find out.

Being an “agile” team provides many of these tools. Small iterations keep you from getting hurt too bad along the project. They also allow direction changes to come from stakeholders (although I’ve never seen an actual stakeholder remain a part of an agile team long term – the stakeholders I’ve seen have always assigned a second-rate proxy after the first couple of iterations). The tests written during development and keep the successes alive and in the knowledgebase. They also encourage the “I don’t know” behavior.

The bottom line is that we should be justifiably proud of our failures, much in the same way we are of our successes – as long as we’ve learned the lesson those failures are trying to teach.

There are a few quotes regarding this topic that I really like:

Samuel Smiles

It is a mistake to suppose that men succeed through success; they much oftener succeed through failures. Precept, study, advice, and example could never have taught them so well as failure has done.

We learn wisdom from failure much more than from success. We often discover what will do, by finding out what will not do; and probably he who never made a mistake never made a discovery.

Mohandas K. Gandhi

Freedom is not worth having if it does not connote freedom to err.

Robert F. Kennedy

Only those who dare to fail greatly can ever achieve greatly.

Robert Frost

The best way out is always through.

Word 2007 Test Post

This is a post to see how things look when posting from Word 2007. If this works out ok, I'll be using this for my publishing from now on.

Photo Test

This is a picture of my extended family on my Mom's side (Anderson). My Grandpa Anderson is standing in the middle of everybody. I'm the little boy standing up on the far right side. This was taken in the late 60's sometime. I'm sure one of my sisters will tell me exactly when it was :-)

Added note @ 9:10 5/14/2008 - MS Word 2007 isn't going to cut it as a Blog editor. I tried posting this from Word, and the image didn't make it, I also had several sections below where I had code fragments and other formatting things embedded in this post. None of them worked as I expected them to. Looks like I'll keep using the online editor for posting for the near term. If anybody has found something better, please let me know in the comments.

Sharing A USB Drive On XP / Vista

I recently needed to share my USB hard drive on the network, and had a lot of problems making it consistently available as a share. After trolling around on the internet, I found the answer -- since this took a while to find and debug, I'm documenting it here.

In regedit, find the key in HKLM (HKey Local Machine):

\System\CurrentControlSet\Services\LanmanServer\Parameters

Set the parameter IRPStackSize to a value 3 higher than it currently is, and reboot. You may have to do this more than once. If this key doesn't exist, create a DWORD key and set the value.

On the two systems I did this to, I ended up with values of 17 and 18.

The Parable of Everybody, Somebody & Nobody

I need to attribute this, but this story popped into my head last night. I believe I heard it in church about 30 years ago (man, it's embarrassing to say that)...

All the people wanted to get back to Heaven, and there were many tasks to perform to get there. Everybody was sure that Somebody would do the work. Anybody could have done it, but was waiting for SomebodyElse to do it. Somebody got angry because it was Everybody’s job. Everybody got angry because he thought that Anybody or SomebodyElse should do it. Somebody said that she thought it was already done, but didn't bother to check.

Finally the day of reckoning came. Everybody fought to be first in line for the rewards. Somebody was crying because SomebodyElse was pushing and giving cuts. Nobody was patiently waiting for her turn.

Nobody was the only one who made it into Heaven. She was the only one that did the tasks that Everybody, Somebody, and SomebodyElse should have done.

The Moral: Don't Procrastinate. Don't let Nobody be rewarded for things YOU can do.

Small Teams

My wife and I went to the "Engineering Open House" at NC State with my son Richard last Saturday. They had many cool things on display, and there were a lot of people there. Richard is very interested in doing something technical, but isn't sure what yet.

The most interesting thing that I did there was spending about a half hour talking with Grayson Randall who designed the Lone Wolf autonomous vehicle that NC State entered into the DARPA Urban Challenge contest. Grayson is a really interesting guy and has a lot of cool stories to tell. I was asking him about the development process and team they used to produce the control and management software for the 9 dual core computers they have embedded in the trunk of their Lotus plus the 4 single board computers they have in the front of the car. He said that there were 6-9 people who spent a couple of years developing this software, with various teams implementing hardware at the same time.

Having been involved in systems design, I can know how hard it is to develop both hardware and software at the same time, so getting it all running is amazing all by itself. The point that sticks out to me most of all though is that a small motivated team can accomplish more than a large one in nearly all cases.

As teams grow beyond single digits two things happen:

1. Inertia kills agility. Too many people are too hard to switch quickly. With small teams a quick meeting can convey the essence of the change. Large teams take exponentially larger amounts of time and effort to simply communicate.
2. Inertia kills motivation. This is obviously not true in all cases, but in the teams I've seen, there is a direct relationship between the motivation of the team and the size of the team. I've seen too many cases on large teams where "everybody thought somebody would fix it".
   

Note that I'm not saying that small teams are the only ones that can succeed. Simply that in my experience, small teams are more likely to.

Hosted Services

First Amazon created EC3, now there's Google App Engine. I think companies providing 3rd party hosting environments are in for a tough time in the future. It's going to be tough to compete on volume / size / price. They're going to have to provide niche features that Amazon / Google don't have.

For developers and startups, I think this is a Very Good Thing.

New Blog Elements

If you're reading this in an aggregator, you won't be able to see this, but on my blog home page, I've added a few new interesting time wasters. Specifically:

• Visitor Map - This is from ClustrMaps and shows how few readers I actually have :-)
• Recent Interesting Sites And Articles - This has three things:
• Recently "Shared" Google Reader Items
• Recently "Starred" Google Reader Items
• Recent del.icio.us Links

So for all those times you don't have anything better to do, you can see what I'm looking at...

Google Apps

I've recently setup a couple of my domains with Google Apps, and I'm very happy with it. 6G+ of email space per account, 10G+ of space per domain for wiki stuff, and lots of document and spreadsheet goodness all around. You can check out either http://start.mackelprang.com or http://start.mackelprang.org to see what's there.

The main site for me will be the mackelprang.com one (http://www.mackelprang.com). The mackelprang.org site will be used for the "family at large".

Setting up the domains was a very painless experience compared to what it would take doing it at a hosting site. I've migrated nearly all of my local hosting dependencies to my Google Apps sites, and I'm very pleased. I'll keep you up to date as things progress.

Starting Up. Again.

So Andy tells me he wants to blog again, and guilts me into joining him. I have a lot of article topics pending, so I'm going to spend a couple of hours a week getting them out here. Hopefully I'll be more diligent this time than last...