Bender's Blog

Stone Soup

James Bender — Sun, 06 Sep 2009 20:30:11 GMT

As a consultant, I work with a lot of clients of varying backgrounds, skill levels and willingness to explore new techniques and tools. In addition to my development/architecture duties, nowadays I’m often brought into a team to provide mentoring and perform assessments. This takes a variety of forms but there is almost always some effort needed to “evangelize” new ideas and approaches to clients.

Some clients are very open to this. They recognize that I’m there for a reason and that my advice can help them get from where they are to where they need to be. Sometimes the ideas I provide and the steps needed to implement them are difficult and scary, but in the end they will be better off.

Then, there are clients who are a little more resistant. This is almost always based on fear. Mostly fear of the unknown. They’ve been doing things they way they do them for years. They feel pain but it’s the pain they know. They’ve noticed all the changes in development in the past several years, but haven’t been able to keep up on all of them. Usually they’re in a situation were an tool/technology/technique needs to be vetted before it is used. In the meantime they need to continue supporting their business users with what’s available to them. They find themselves behind the technology wave and getting back on top seems like an impossible task.

Additionally, they know how to be “successful” with the tools and techniques they have now. It’s what they know. Introducing new tools and techniques increases the chance of failure. People tend to put too much emphasis on the negative side of failure without acknowledging the learning experience it provides.

So, how do you win these people over?

The Wrong Approach

As a passionate technologist, sometimes my first inclination is to come in and try to get them to change everything. Right now. This takes fear and turns it into outright panic. From their point of view you’re asking them to throw out everything they know and start over. This isn’t like asking someone to move from Java to .NET or from Visual Basic to C#. The jumps we’re asking people to make are much more difficult. Introducing new developers to concepts and practices like TDD or Inversion of Control require them to make a significant leap in abstract thought. Making a change from Web Forms to MVC, or from Remoting to REST based services takes a major change in the way we think about designing and building applications.

But that’s just what’s on the surface. When you walk into a situation were a team has already been working diligently on an application, which is usually the case, you’re in an indirect way leveling criticism against their development skills. And the more you insist the it must be thrown out and re-done your way and dig your heels in, the more biting that criticism is. No one likes to be told their baby is ugly.

What I’ve Learned

When I was in the third grade I remember reading a book called “Stone Soup.” It was the story about three soldiers who were on their was somewhere and stopped in a small town. The soldiers were hungry, and proceeded to knock on every door in the town asking for food. The townspeople knowing that the soldiers would be very hungry and not wanting to share their food decided to tell the soldiers that they don’t even have enough food for themselves, let alone anyone else. The soldiers are able to see through the ruse however and come up with a plan. The tell the townspeople that they can teach them how to make soup using nothing but stones. The set a large cauldron of boiling water, containing one stone, in the center of town. The townspeople begin to gather, curious about how they are going to make soup out of a stone.

The soldiers make a big show of tasting the soup and claiming it to be, almost, the best soup they’ve ever had, remarking that the only thing is needs to make it perfect is a few carrots.Still curious, a farmer runs to his root seller and returns with some carrots which the soldiers add to the soup. The soldiers go through the same “tasting ritual” this time claiming that if they only had a few potatoes, then the soup would be perfect. Next celery. After that cream. Then meat. You get the idea.

I have found that this approach works well with developers too. We’ve all heard the phrase “Don’t boil the ocean” this is a great technique on how to avoid getting into that trap. Instead of asking a client to take on a dozen new tools, frameworks and techniques, introduce them one at a time. Let the client see the value and point out that by taking another step (when the clients team is ready) will yield even better results. Don’t get hung up on going back and re-doing their existing application. If it’s working now, it’s probably good enough. The benefits you gain by introducing these techniques for new development are not necessarily going to provide an equivalent when used to refactor an existing code base. If there is a benefit to be had, and you’ve used this technique correctly, the clients developers will be the ones who start to champion that cause.

This technique is not an overnight solution, but it is a lasting one. Take your time. Convey your excitement, but also remember to be patient. Keep your changes small and manageable. And enjoy your soup.

Getting Started with WCF Slides and Code Sample from CINNUG

James Bender — Thu, 03 Sep 2009 12:17:50 GMT

Better late than never…

Seriously, sorry to everyone who’s been waiting for these.

I had a great time speaking in Cincinnati last week and meet a lot of great people. I hope to see you all again soon.

Burn Down Your House

James Bender — Sun, 16 Aug 2009 18:42:13 GMT

I had the luck of being able to participate in a “Community Summit” the day before DevLink in Nashville. In addition to other activities, and some (GREAT BBQ!) there was an open space on how to be a better speaker. A couple people were surprised when I suggested a practice I employ.

Occasionally I’ll take a presentation (slides, demo, etc.) that I’ve given several times and just “throw it out.” Even if it’s a popular talk. Even if I am comfortable giving it. Even if I think it’s perfect. Especially if I think it’s perfect! I throw it out and start over from scratch.

Why?

Probably the biggest reason I do this is that technology and attitudes change. They change very quickly. I’ve noticed a lot of speakers/presenters/whatever try to address these changes by adding “appendixes” to their talks. You’ve probably seen this; a well put together albeit dated talk suddenly veers off in an unexpected direction to accommodate a point release that came out a month ago. It’s jarring. It’s awkward. It feels “bolted on” (probably because it was) and I’m not a fan. I understand that sometimes, especially if you’re talking about “bleeding edge” technology or tools there are going to be last minute changes and patches that you might want to address. That’s fine. But if we’re talking about the delta between a “.0” and a “.5” release you should have (and take) the time to incorporate those changes in a way that keeps the flow of the talk smooth.

But I’ll throw out presentations sometimes even if this isn’t the case. Especially if it’s one I’ve given several times. Re-building a presentation causes you (like it or not) to re-think your approach to the topic. You can’t escape it. If you’re re-building a one year old presentation you have another year of knowledge and experience to put into the presentation. Not just in the topic you’re speaking on but in speaking in general. I’ve been speaking for over two years. In that time I’ve only used one slide deck and demo that wasn’t mine and I wasn’t allowed to alter. I did that presentation under protest. In those two years I’ve put many slide decks and many demos together. I can tell you without a doubt in my mind the presentation I put together last week is more than 100 times better than the first presentation I created.

The last reason is that when I give the same presentation again and again it can get boring. After awhile I start to feel like I’m going through the motions. When I feel like I could sleep walk through a presentation, I take that as a bad sign. Re-building is a way for me to re-capture that inspiration to speak on the topic in the first place. I’m a fan of the XBox game “Civilization Revolution.” I like the whole game, but one of my favorite parts is the beginning where I create my cities and kind of “mark out” my territory. I think it’s exciting trying to beat my opponents and lock up key strategic positions and resources. Once my territory is established and my cities well defended, it’s still fun, but not as much fun. I think it’s a creative thing. Good developers are like this too; we get excited about creating new things. That’s why most of the developers I know will jump at the chance to do some “green field” development and would fake their own deaths if they though it would get them out of maintenance. Presentations are the same way.

Again, this is what works for me.Your mileage may vary. But if the circumstance allow give it a try and let me know how it worked out.

Later.

Exceptions Happen, Part 1

James Bender — Tue, 11 Aug 2009 19:11:20 GMT

You might thing you’re special, but your not. And sooner or later it’s gonna happen to you too. Your WCF Service is going to encounter a *gasp* Exception. Do you know what to do when it does happen?

Scott Hanselman wrote a terriffic blog post on exceptions. It’s a great place to start and if you haven’t read it you should. I wrote a post last year about working with the WCF Fault Contract. But there’s more than one way to skin this cat. What I’m going to be focusing on in this series of posts are the ways you can deal with exceptions in WCF and how to communicate what’s happened to your client.

In the first installment we’re going to look at how exceptions get received by a WCF client and how the WCF channel reacts to exceptions. Let’s start with what happens if you just throw a normal .NET exception. For this example we’ll be looking at a mock up of a service to return prices for stocks based on a ticker symbol.

The service contact:

   1:      [ServiceContract]

   2:      public interface IMyWcfService

   3:      {

   4:          [OperationContract]

   5:          decimal GetStockPrice(string symbol);

   6:      }

And the implementation:

   1:      public class MyWcfService : IMyWcfService

   2:      {

   3:          public decimal GetStockPrice(string symbol)

   4:          {

   5:              switch (symbol)

   6:              {

   7:                  case "MSFT":

   8:                      return (decimal) 1.41;

   9:                  case "IBM":

  10:                      return (decimal).89;

  11:                  case "JAVA":

  12:                      return (decimal).10;

  13:                  default:

  14:                      throw new ArgumentOutOfRangeException("symbol", "bad symbol");

  15:              }

  16:          }

  17:      }

Since this is a contrived demo, we only handle three symbols and return a static value. This does however provide us with an opportunity to see how .NET exceptions work in WCF. If we receive a symbol that is not in our list, we are throwing an ArgumentOtOfRangeException. If we were using this as just a .NET object we wouldn’t have a problem; either our code would catch the exception and do something with it, or it would bubble up to the user.

Our client is a winform application. The important part is the call to our service (via a proxy of course):

   1:  public partial class Form1 : Form

   2:  {

   3:      private readonly MyWcfServiceClient _proxy;

4:

   5:      public Form1()

   6:      {

   7:          InitializeComponent();

   8:          btnCallService.Click += CallService;

   9:          _proxy = new MyWcfServiceClient();

  10:      }

11:

  12:      public void CallService(object sender, EventArgs e)

  13:      {

  14:          lblResult.Text = _proxy.GetStockPrice(txtSymbol.Text).ToString();

  15:      }

  16:  }

So all we’re doing is grabbing a value (the ticker symbol) from a text box and passing it as an argument to the service. The result is used to set the value of a label control. When we run this and feed one of the three symbols that our service uses, the expected happens: a value is returned and set to the text of the label. When we provide an unsupported symbol, we get an error:

The exception text should look familiar to anyone who has worked with ASP.NET…

System.ServiceModel.FaultException: The server was unable to process the request due to an internal error. For more information about the error, either turn on IncludeExceptionDetailInFaults (either from ServiceBehaviorAttribute or from the <serviceDebug> configuration behavior) on the server in order to send the exception information back to the client, or turn on tracing as per the Microsoft .NET Framework 3.0 SDK documentation and inspect the server trace logs.

Like ASP.NET, WCF will not return detailed exception information to clients as a security measure. Like ASP.NET we have the ability to change the configuration to return more detailed exception information. One line nine below, we have set the includeExceptionDetailInFaults value to “True”:

   1:  <?xml version="1.0" encoding="utf-8" ?>

   2:  <configuration>

   3:    <system.serviceModel>

   4:  ...

   5:      <behaviors>

   6:        <serviceBehaviors>

   7:          <behavior name="Service1Behavior">

   8:            <serviceMetadata httpGetEnabled="True"/>

   9:            <serviceDebug includeExceptionDetailInFaults="True" />

  10:          </behavior>

  11:        </serviceBehaviors>

  12:      </behaviors>

  13:    </system.serviceModel>

  14:  </configuration>

This results in the details of the error message being passed back to us:

Like ASP.NET, this can be OK for development, but is not a good idea for production.

Let’s make a few changes to our client application:

   1:  public void CallService(object sender, EventArgs e)

   2:  {

   3:      try

   4:      {

   5:          lblResult.Text = _proxy.GetStockPrice(txtSymbol.Text).ToString();

   6:      }

   7:      catch

   8:      {

   9:          MessageBox.Show("Service call failed");

  10:      }

  11:  }

By catching the exception we can let the user know that something happened and handle it gracefully. Running the application and use the symbol “ORCL” causes the exception, which is handled:

So, we can just re-submit a supported symbol right…?

Uh-oh.

Turns out that when a WCF service throws a normal .NET exception, it faults the channel. Any subsequent calls to the channel results in a CommunicationObjectFaultedExcption being thrown immediately. The channel cannot be salvaged; your only option is to throw it out and recreate it. The proxy implements an interface called ICommunicatioObject that has a Faulted event that we can subscribe to.A few more changes to our client…:

   1:  private MyWcfServiceClient _proxy;

2:

   3:  public Form1()

   4:  {

   5:      InitializeComponent();

   6:      btnCallService.Click += CallService;

   7:      _proxy = new MyWcfServiceClient();

   8:      ((ICommunicationObject)_proxy).Faulted += RecreateProxy;

   9:  }

10:

  11:  void RecreateProxy(object sender, EventArgs e)

  12:  {

  13:      _proxy = new MyWcfServiceClient();

  14:  }

… and now our client is able to recreate the proxy if a communication fault occurs.

This way of dealing with exceptions in WCF works well if you are a client of a service that you may not control or have the metadata needed to create a fault contract for. Otherwise, using the FaultException class and/or WCF fault contracts are a better way to go. I’ll be covering them more in detail in the next couple posts.

Code on!

Make your investment count

James Bender — Sun, 02 Aug 2009 14:05:05 GMT

I recently had a conversation with a friend and fellow developer who was very excited. His company recently welcomed a new CIO to the organization, who had some, comparatively, progressive idea. One of his first actions was to increase IT development spending by several million dollars to tackle some projects that had had to be put off over the past few years, including renovating several applications that we’re quite performing up to expectations.

Unfortunately, while the CIO’s spirit was in the right place it became clear that his money was not.

The various development groups began developing applications the way they had always done, but made no effort to update their tools, techniques or practices. Instead of spending part of their substantial investment to introduce things like Agile methodologies, Test Driven Development, Web Standards, Source Control policies or automated builds, they proceeded to develop a whole new collection of applications like they had been developing them for years.

The group knew that these old practices had led them to a lot of pain in the past and needed to be revamped. But the organization placed value on raw lines of code and not the quality of what was being produced. As a result, those applications that needed “renovation” were simply ported from .NET 2.0 (and in some cases 1.1) to 3.5. Management was surprised when “upgrading” these applications did not result in large performance and stability increases.

Making a lot of changes to the way we work as developers can be scary. There’s a lot to learn, it seems complicated at the start, and no one wants to risk looking stupid. But it’s also important for us as individuals and software development in general to be willing to examine and investigate new techniques and tools that will make it easier to develop higher-quality code more efficiently. Keeping an open mind will unlock a lot of doors to improvement.

Companies need to understand that their code is an asset just like a building, vehicle fleet or piece of manufacturing equipment. You wouldn’t dream of letting those things fall into disrepair, so why are companies OK with their code base rot? When making an investment in IT, it’s important to understand where that money is going, and what it’s going to buy you in the long run. If you have a code base of dubious quality and pay for large teams to simply “plough ahead” you will just end up with a larger base of low quality code.

2009 Columbus Give Camp is in the books…

James Bender — Tue, 21 Jul 2009 18:50:54 GMT

… and it was a tremendous experience!

The goal of a Give Camp is to unite non-profits that need technical assistance, be it a new web site, help with a CRM or making changes to an existing line of business application with passionate geeks in the area who are willing to give a weekend to help these non-profits accomplish their goals.

This year, in Columbus, about 45 software professionals came together to help eight non-profits. The results were amazing. In about 48 hours, eight full scale applications were either completed, or nearly completed. Most starting from scratch. It was great to see the variety of technologies and talents in one place and one time. It was also great to see the results a small but committed team of developers could create in a short period of time. Truly amazing! I want to thank all the volunteers who came out to help. A weekend can be a big thing to give up, and the Give Camp organizers and non-profits are extremely thankful of your efforts.

I would also like to thank all the non-profits that participated. We had a great time getting together and learning from each other while helping you.

I would also like to thank our sponsors. Quick Solutions for providing us with a great workspace, and soda and coffee through the weekend. Discount ASP.NET for providing hosting for the non-profit applications. Tech Smith for providing funds and licenses of their amazing products. Telerik provided us with licenses for some of their products and swag. Microsoft for providing funds and swag. eRubycon for providing a free pass to eRubycon 2009. And The Sophic Group for sponsoring dinner on Saturday night. Please remember the support these sponsors provided.

I would like to single out two sponsors who went above and beyond for us: Potbelly and Pei Wei. One of the most difficult things about organizing an event that lasts all day is feeding people. When that even spans multiple days AND encourages participants to stay over-night, that task is even harder. Potbelly and Pei Wei made some of those meals a whole lot easier for us! Please remember them if you’re in the Polaris area at lunch or dinner time (Potbelly is here, Pei Wei is here)

See you all at Give Camp 2010!

I’m Following Rod Paddock at Codestock?!

James Bender — Thu, 25 Jun 2009 03:46:07 GMT

Codestock is this weekend in Knoxville. You can check out the agenda page here and see that there are some great, very smart people speaking there. With seven tracks over two days, plus open spaces, there’s something for everyone at this great event. I was honored to speak at the first Codestock event last year, and I’m thrilled to be back!

I’ll be presenting “How to make your application awesome with JSON, REST and WCF” in which I’ll explain why REST is the “new” hotness (turns out it’s not that new) and how to take advantage of it with WCF. You’ll also get to see some cool JQuery and ASP.NET MVC stuff as part of the talk. It’s the first time I’ve given this talk, so I’m very excited!

Turns out I’m following Rod Paddock. Yeah, that Rod Paddock. Editor in Chief of CoDe Magazine, author of many books, international speaker and Microsoft MVP. By contrast, I was all excited this morning because I found a $5.00 bill in my pocket that I forgot I had.

Ron Paddock followed by James Bender. Kinda like…

	followed by
	followed by
	followed by

In all seriousness, I’m really looking forward and VERY happy to be speaking at Codestock. It’s a must-attend event and if you’re not going, well, you should go!

Camping without the insects!

James Bender — Mon, 15 Jun 2009 22:31:23 GMT

Notice I didn’t say “bugs” though….

The Columbus Give Camp is July 17-19 and will be held at the Quick Solutions office

.What is a “Give Camp?”

The goal of the Give Camp is to pair charities that have technology based needs with people from the development community who are willing to donate their time and help those charities out. We will start on Friday the 17th, and work STRAIGHT THROUGH (OK, you don’t have to stay overnight if you can’t) until Sunday to do our best to provide the charity with what they need.

We are looking for both volunteers and charities. If you are interested, or know someone (volunteer or charity) that might be interested, please visit the Give Camp website and register.

Indy Code Camp Recap

James Bender — Sun, 17 May 2009 02:57:59 GMT

Thanks to everyone who attended my talk on custom WCF behaviors at the Indy Code Camp. I hope you all found the topic interesting and the content useful.

You can get the slides and code samples here:

For those who might be interested, I’ll be presenting an Intro to WCF talk at Cincinnati .NET Users Group in the future. More information will be posted here in the future.

If I Do A Good Job, Can We Go To Dietsch Brothers for Ice Cream After The Meeting?

James Bender — Sun, 26 Apr 2009 23:28:20 GMT

This Tuesday, April 28th, I’ll be speaking at the Findlay Area .NET User Group.

I’ll be presenting “How I Learned To Love Dependency Injection,” which if my .NET Kicks stats are to be believed, is turning out to be quite the popular talk. The meeting is at the Marathon Oil building in downtown Findlay.

I spoke at this group a couple of years ago and had a GREAT time. I’m excited to be going back!