What tools do you use? If you are reading this I bet you use some flavor of Visual Studio and some form of source control, but like most developers your tooling stops there.  Why?  Have you tried the various Visual Studio add-ins like ReSharper or CodeRush?  How about SQL Schema diff tools like SQL Compare from Red-Gate? How about a build server like Team Build or Cruise Control?

Most developers I know would answer no to most of those questions.  And honestly, I don't get it.  Do you like spending time writing reams of similar code?  Manually diffing schema? Figuring out why a build doesn't work in a new environment?

"Ryan, those things are too expensive.  I could never get those things approved!" I call bull.  Have you tried to use them? Have you seen productivity gains?  If so, I bet it would be a rather easy sell to your manager.  Do a simple ROI on it and you'll be amazed at how cheap most of these tools are!

If you are looking for the quick win, create a build server.  Once you see how easier deployment is when you can xcopy a build to a new environment you'll be sold.  Then you add in things like unit tests and longer running build verification tests and you'll be amazed.  You'll start to trust your builds and rollouts to new environments won't be feared.

Here is another thing I don't get.  Developers, as a whole, put up with a lot of friction before doing something about it and I'm not sure why.  We spend all day writing applications that make other people's lives more productive yet we will put up with friction at almost ever step of the way.

"But that's the way it is. Writing software is hard and this is the way it's always been."

Yeah, writing software is hard, but that doesn't mean we can't write software to make it easier!  There are two tools that I use everyday that you can't buy anywhere.  OutWit, a Outlook add-in that creates TFS work items and IntelliPages, a small applications that lets us search our company directory/quick dialer.  Both of these applications make my life easier and neither one existed until a developer on the team decided it to make time to bring it life. (I made OutWit and Ray made IntelliPages, which has been so successful internally it's now part of our standard desktop image across the organization. :))

Another tool I build/use is a simple command line app that is part of each solution and is tasked with knowing how to promote builds from one environment to the next. Get the build from the build server, put in environment, update Team Build with new environment information, that sort of thing.

My point is that as developers you need to look outside of Visual Studio more often and find tools that lower the amount of friction you deal with daily.  If you are adamant that there is no way you can buy a tool, then build it.  You have the power. :)

In the comments to my post yesterday (comments meaning the only one I got), my friend and coworker Richard Lowe pointed out that working with new technology also adds business value.  I have to agree with him.  Staying up to date with technology, whatever technology you use day to day, does increase business value. I took that as a given because, in my opinion, if you don't stay up to date then you become technically irrelevant and technical irrelevancy adds negative business value.

Negative business value?  Yeah, negative business value.  You actually becoming a liability to the company by not introducing new technology.  Tool sets, frameworks and programming languages all have an expiration date (within reason. I know COBOL is still alive and kicking). When they expire, your company is now in a horrible situation (especially if that expired technology is running a core business application).  Staying technically relevant removes that liability.

"So Ryan?  What is technically relevant?"

Glad you asked!  In my opinion there are a few things that every developer should be aware of right now.  Take note that I didn't say you should be using, you should know or you should be competent in.  These are things that should have at least crossed your radar so if somebody talked to you about it you would have some basis for discussion.

1.) Unit Testing

Unit testing is pretty much beyond mainstream.  The tools to do unit testing are now shipping with Visual Studio. 

2.) Model-View-Controller/Model-View-Presenter

These patterns have been around a long, long time (so long in fact that they have been renamed, but nobody goes by those names yet). A lot of web and windows frameworks that are coming out (or in the Java world have been out for a long time) use these patterns.

3.) Object-Relational Mapping

I don't care what tools you use.  If you are a developer you owe it to yourself to at least know about O/RM.  It will save you boatloads of time and money. (See: NHibernate, LINQ to Entities, LLBLGEN, iBatis, etc.)

4.) Dynamic versus Static languages

With languages like Ruby and Python being mainstream, C# adding dynamic support (Dynamic via Static) and the addition of the DLR to the .NET runtime, you need to have some understanding of why people even cared about the issue to begin with.

5.) Messaging

With the push to create isolated systems and cloud computing being "The Next Big Thing", messaging and messaging patterns are starting to get more press.

These 5 things are items that I feel that developers need to have at least heard of. I'm not claiming to be a guru in any of these (especially messaging!) and I'm sure other developers have the 5 areas that they feel everybody should be aware of.  What technologies am I missing?

(Side note: The Metra is all screwed up this morning.  I'm told trains are running 20 mins late then the 7:51 pulls up going from Chicago on the to Chicago tracks.  Sigh....)

Anybody that has worked with me knows that I tend to be an early adopter of technology.  I love playing with Beta, Alpha, CTP and "Here is my bin folder" builds. But sometimes as an early adopter I run into trouble.  Not the kind of "This build borked my machine" types of trouble, but more along the lines of "Boy this is neat but what value does it give me?" kind of trouble.  If I can't find the business value in a piece of code or new technology it's nothing more than a geeky toy.

As a developer it's our job not to just write really awesome code, but to make sure that code adds value to the core business.  Sometimes I struggle with that.  When I'm adding some lame excel exporting feature instead of playing with Aspect Oriented Programming or when I'm fixing some edge case bug instead of doing some crazy Meta-Programming I have to remind myself that the things I am doing are increasing productivity in some other part of the business.

Sometimes though, we need to take a step back and look at those new technologies (I just came back from PDC so my brain is FILLED with new stuff).  Do these new technologies increase business value?  How-so?  Sometimes the question is easy enough to answer (Windows will crash less), other times it's harder (Oslo will help you create textual DSLs).  Whenever I'm in this position, the first thing I do is play with the technology.  How long is taking me to understand it?  Is it lowering the amount of code that I have to write, or just moving it around (C# to Xml configuration)? Is it lowering the amount of friction in my day-to-day life?  Once I can answer those questions I can move forward and confidently promote new technologies to the business (or not as the case may be).

When you start to think of terms of business value interesting changes start to take place.  When you are what feels like a death march project you start to ask around.  What value are we providing?  Who needs this software?  What is this application going to do for them day-to-day? Are we really making work easier?  The answer to those questions will either motivate you because you know you are providing value, or the questions start to float up the chain of command and project goals start to get re-aligned.  There have been a few projects in my life that as stake-holders and priorities changed no one was really sure why the application was being built.  Asking questions has helped to get those projects back on the right tracks.

In the end, my point is simply that when you are implementing a new feature, fixing a bug or working with brand new technology try to keep your focus on business value and not what shiny new toys you want to play with.

One of things I've been trying to put together in my spare time is a home media center.  I got an XBOX 360 and using that as my Media Center Extender my goal is to stream backups of my DVDs that I ripped to my PC that is running Windows Media Center.  Unfortunately I haven't been able to come up with a solution that I find acceptable.  I attempted to use Transcode360 to stream VIDEO_TS but it doesn't appear to even see the files on my machine.  I then converted my VIDEO_TS files to WMV and while I can stream that, losing FF/RW is unacceptable. (Side note: Maybe FF/RW works with WMV but trying to use the XBOX controller as a remote is painful.  I should probably pickup a real remote for it.  That will go on my list of things to buy.) 

Does anybody out there have any suggestions as to what I can do to realize my dream of a DVD jukebox?  I haven't attempted straight-up MPEG-2 yet, but that is my next step.  Any help would be appreciated!

Something that has running on a background thread for awhile is "How do we implement pub/sub messaging?".  One of the cons to having very silo-ed systems is how do you handle the cross-system reporting?  For instance: When you want to get a list of all the customers that have more than 10 licenses and have more than 20 open tickets (totally contrived but you get the idea).  That query spans 2 different domains: Billing and Support.  Support knows how many tickets somebody has and Billing knows how many licenses a customer has but it's not like you can "join across systems" to get that information.

Enter the datamart! Wouldn't be great if somehow each source system could populate a central repository of data with the key pieces of data that it has authority over?  Yeah that would be great! They way we have been approaching that is having snapshots of our source systems update a central warehouse every few hours.  While functional, it leaves a lot to be desired.  Data can be out of date, when the update is happening you might get funky results, etc.  So in our quest to get realtime reporting we are looking to implement some sort of messaging sub system in our applications so we can just "write the updates to the wire" which the datamart (or any other interested system) could read.

Enter pub/sub messaging!  Pub/Sub seems ideal for our needs, but how do we go about implementing it?  If you ask MS the answer is "Install BizTalk!".  Now I don't know about you, but I tried to install BizTalk once.  The experience taught me that I don't want to do it again.  It seems WAY overkill for what we are trying to do.  We don't need orchestraions (or maybe we do? Problem is, to know if your problem requires it you have to implement BizTalk first and then see if it works.  That doesn't sound like a very agile solution.). So if BizTalk isn't the answer, maybe using something like NServiceBus, SimpleServiceBus or MassTransit is?  The problem here now is that I don't have enough information to make that decision!  Like a lot of Open Source applications, all 3 suffer from poor documentation.  Not on the implementation side (from the "How do I make it go?" point of view, all 3 have pretty good documentation) but on the "Is this going to solve my problem" front I can't find anything.  The last option is SQL Service Broker.  From a technology standpoint SQL Service Broker is interesting.  Managing durable messages and conversations inside of your database.  From a developer stand point, I don't think I like it.  I'm back in TSQL hell, but now writing TSQL that isn't standard against a product that is probably used by only 1% of the SQL Server install base.  I don't think there will be a lot of Google results when I run into problems no matter how good my Google-Fu is.

So that is where I am at today.  Any advice?  If my thought processes keep dead-locking trying to come up with a solution, I think I'm just going to start with NServiceBus and see what happens.

(Lisle to Union is going to be a recurring series.  I'm going to attempt to write daily my thoughts on what I'm currently working on.  As to the name "Lisle to Union"?  That's the train I take to get into work every morning. :))

In my current project we are consuming data out of MS CRM.  Accounts and contacts to be precise. Pulling data out to display it is relatively easy using their web service apis and we are quite happy with the result.  Having one silo-ed system that is in charge of a very specific domain and requesting data from that domain from very well defined end points jives with my line of thinking.

But, there is one problem with not having control over the domain.  The problem is how do you find out about changes to data that you are interested in?  Account name changes, contact name changes, merging of entities, etc?  Luckily MS CRM has a rich plug-in model that allows you to receive messages when "interesting" things happen in the MS CRM pipeline.  I say "interesting" things because you can hook into every event that you need.

When I first started looking into the MS CRM Plug-in model I first thought "This so extensible that it is useless". The amount of configuration and registration that is required is quite frightening.  The awesome part is that the CRM 4 sdk has tools in it to make it super easy.  They have a plugin registration tool that makes it a snap to register a plug-in for the events you are interested in and a developer tool that makes it easy to re-register any changes to your plug-in during development. 

When you get a message from MS CRM you are passed a Context object that contains the entity that changed (which was the entity you said you wanted in the plug-in registration) and (here is the interesting part) the actual message that MS CRM processed.  You don't get a "here is the before and after" message (which is what I was expecting).  Since all of the APIs MS CRM uses are all passed on the Command Pattern, the easiest thing for them to do is pass you the command that it used.  In all honesty I find this pretty slick. (and I'm happy that we are using the Command Pattern in my current app (not through-out but in places where we didn't want to play the game of "What has changed on my data model?".  That is not a fun game to play.)

Unfortunately, for my first plug-in it seems I have tried to tackle one of the hardest problems in MS CRM.  Entity Merging.  There aren't a lot of examples out there for MS CRM and I can't find a single one for entity merging.  As soon as I get it figured out I'll post more in depth on it.