With all the talk of being Agile, one has to wonder if anyone cares about shipping.  We focus a lot on the methodologies and practices that go into creating software, but we don't talk all that much about shipping.  Software doesn't exist until it's shipped.  No money is made from a great piece of software that isn't available.  No money is made from having a really kick ass Agile process if you don't ship.  It's not all about money, but without money we don't get to "play another game of pinball".  As Sam reminded me today, it's all about getting that next game.  It's all about shipping.

Those of us living in the world of software need to remember why we're in this business.  It's not about process, it's not about methodology, it's not about how Agile you are. It's about creating kick ass software that users love.  Users can't fall in love with something that isn't shipped.

In this day and age Agile seems to be where it's at.  If you're Agile, you're good.  If you're Agile, you have no bugs.  If you're Agile, you respond quickly to change.  If you're Agile, you'll build what your customer wants. 

It's easy to say you're Agile.  It's even easy to think you're Agile.  I wonder though, are you really Agile?  Are we Agile?  Am I Agile?  What does it even mean to "be Agile"?  Is it even possible?

What does it take?  Do you have what it takes?

Over the last several months I've grown to have an amazing amount of respect for people who write technical books.  It's an amazingly time consuming process that involves a lot of staring at the screen wondering what the heck to write next.  There are an infinite number of ways to phrase every sentence, and your choice has a huge impact on whether or not the reader will get what you're trying to say.  On top of that, for me, writing is nowhere near as interesting as actually using the technology you're writing about.  I can't tell you how many times I've wished I could get the heck out of Word and into Visual Studio.  Layer on top a busy work and family life and you have something that I've found amazingly difficult.  Since I have a full time gig I have to write in the evenings and weekends.  With a wife and two young kids I'm not exactly oozing with tons of free time.  Writing is amazingly difficult. 

Rather than end this post and leave it as a paragraph of me complaining about how hard I'm finding writing, let me leave you with some tips that I've found to help in the writing process.

• Find someplace quite to work.  Unlike programming (and other tasks) where a little bit of background noise and/or music can be beneficial, writing needs quite and needs thought.  Find someplace you can think.  Don't try and get a little bit of writing done while you try and do something else (such as watch after the kiddos).
• Start with an outline of what your going to write.  Include the key goals that you have for each section and make sure you address each goal before you finish the section, or chapter.
• With your first draft don't worry about how terrible things sounds, how rough around the edges your points and/or description are, and how utterly crappy things flow.  Get your thoughts on paper.  Once you get everything out, go back and revise mercilessly until things sounds the way you want.
• Always think about the reader.  How will they expect to consume the information you're presenting?  What will they arleady know? What might they need to be reminded of?  How can you leverage what they know to help them learn what you're writing about?
• Don't be boring.  This might sounds obvious but I've found it very hard to present everything you want the reader to learn without having things turn into an unending flow of technical details, which results in boredom.  It's important to remember the reader needs breaks, encouragement, and direction.  And they also need to not be bored.
• Instead of writing blog posts about how hard writing is and then spewing off a bunch of writing tips (as if you have any clue what you're talking about) stay focused on your book and the deadlines you have....doh! :)
  

I'm a big believer in Domain Driven Design (DDD).  I have to admit that I've lost a little focus of late, so I think I need to get back to the basics.  As such, I've just printed out a bunch of experience reports from the Domain Driven Design website.  As with anything, DDD takes practice. What better way to get a jump start than by reading about how someone else has used DDD to create better software?

Over on the XML Team's blog, Avner outlines some VB 9.0 XML changes that will be showing up in the February CTP.   As I've mentioned in the past VB 9's XML features are very compelling, so much so that they have me wanting to write code in VB which I haven't done since I started working with .NET.  The major changes in the February CTP include:

• Attribute axis property is string
• Global Xml namespace syntax has changed
• Added auto-completion
• Xml names are VB symbols
• Improved error handling

For the full details checkout Avner's VB 9.0 Xml in Visual Studio "Orcas" February CTP post.

If you haven't yet, you will...it's just a matter of time. :)  When you do, Getting good with Google Reader is a very valuable overview of the key keyboard shortcuts that you'll need to make the most of Google Reader.  As with most peeps, these are my keys:

j - next
p - previous
v - view in window
ga - All Items
SHIFT-n - next folder
SHIFT-o - open folder

I'll definitely be trying to get used to some of the others outlined in the aforementioned article as well.  The gu keyboard shortcut is definitely the snazziest that I didn't know about.  I think Reader is the most Ajax-irific app I've used thus far, how 'bout you?

Harry Pierson has an interesting post that outlines how he learned to stop worrying and love WCF. In the post, Harry talks about the concerns that he's had regarding the lack of support for long running services in Indigo, and then discusses how a talk with Shy Cohen helped clarify some of the misunderstandings that he had. The primary of which, is that WCF's solution to long running services is Duplex Channel. In fact, Shy confirmed Harry's feelings that WCF doesn't have a real answer to long running services in v1.0.

I found the post particularly interesting since we've been talking about how best to support long running services within our application. One option that we've considered is Duplex Channels, however, we've had some concerns with whether or not the Security folks at our clients would be ok with us opening up a callback channel from the desktops running our software. At any rate I'm interested in what others think would be the "Reese's Peanut Butter Cup of service messaging". Harry's would be "something that has the programming semantics of SSB and the interoperability of WCF". And you?

As someone who spends most of his time in VS.NET I often times desire a nice lightweight text editor. While VS.NET is very powerful, it also tends to fall over when you have a solution with a reasonable number of projects. As I read about Rails, one of the things I often hear is how much people like working with TextMate. Apparently it's a pretty kick ass text editor. It's one "flaw" is that its an OS X only application. I heard a rumor (I don't remember what blog) that the folks over at Intype are creating a Windows text editor that's inspired by TextMate. If it lives up to the hype, it could replace Notepad2 as my preferred text editor in Windows.

DomXml has a nice post that breaks down consulting rates in the IT industry. Prior to joining my current company I worked at a consulting company. During my time there I learned a lot about how consulting companies work. In general, as Don points out, they try and get "more affordable" consultants and employees so that the markup that they receive is higher. I must say that the place I worked was probably much much better than most, however, I was often amazed at the rates that we'd end up charging clients knowing who was going to be working on the projects. For some reason everyone always seem to think that having cheaper, more inexperienced, developers is the way to go since they result in higher margins. While in theory that sounds reasonable it always seemed very shortsighted in my mind. Sure you pay less for a more inexperienced developer, but it also takes that inexperienced developer longer to get things done. Often times much longer. The solution developed is also more likely to be "sub-optimal". What often happens in these situations is the senior developers end up cleaning things up, and making sure "shit" doesn't get shipped.

It's my opinion that having a small, experienced team is the way to go. Unfortunately, in the consulting world this often doesn't work. The way consulting companies make money is by increasing head count. As you increase head count it becomes more and more difficult to find good people. As you hire more and more people, who are no longer as good as you probably would like, you end up putting yourself in situations that are destined for failure. I think most people realize that it's important to hire great people but everyone seems to fall into similar traps. All the sudden a big project falls in your lap. Since you don't have the resources to staff it, you hire a bunch of people. Since you need your resources quick, you drop your quality bar and hire whoever you can. Since you've hired more people, you start making more money. You chase more money, and hire more people. Eventually you have a bunch of people, most of which you have no clue if are any good. You do Ok, ship some stuff and have decent success. You get blinded and all the sudden make the same mistake you originally made and hire more people. Afterall, more people means more money. The majority of big consulting companies have a large pool of resources who are inexperienced, inefficient, yet quite good at making your projects going longer than you'd like. It just so happens that longer projects means more money, and potentially more people. We all know what more people means don't we?

Anyway, I've gone off on a bit of a tangent that I didn't intend. The original point of this post was supposed to be to remember that you get what you pay for. While it might seem strange to pay twice as much for something, whether it be a consultant, a product, or a bag of groceries, you most often times get what you pay for. Or do you?

The LINQ videos seem to be rolling out lately. 

• Wes Dyer interviews Charlie Calvert - download.
• Anders Hejlsberg on LINQ and Functional Programming

Boooooooooooooo! :)  I'd really like to get a new release that includes everything LINQ related that we saw in the May 2006 CTP so I can start updating all my code samples and use all the new wizz bang features that I'm sure they've added.

Update: I think I misread the post above.  The next Orcas CTP isn't being pushed to March, it's just a bunch of LINQ to SQL stuff that isn't making it into February that will show it's face in March.

John Rusk left a comment on my Developers ditching Microsoft for Rails post and brought to light the fact that developers might not be leaving because of what Rails is doing right, but instead because of what .NET is doing wrong.  I definitely agree that many of the reasons people leave the .NET world for technologies like Rails is because working in .NET isn't as smooth as it should be.  One of the things that makes Rails so successful is its focus, and the embracing of constraints.  Rather then trying to be everything to everybody, Rails is focused on a specific vision.  As I've said in the past, Rails is opinionated software.

For those looking for Rails-ish frameworks in the .NET world you might want to checkout SubSonic and Castle's ActiveRecord and MonoRail projects.  I just had De-ja-vu.

I've been reading a lot of stories lately about developers leaving the friendly confines of .NET Land for Rails and other non-Microsoft technologies.  Perhaps the most notable being Mike Gunderloy of  The Daily Grind fame.  You can read more about Mike's journey over on his A Fresh Cup - Notes from a recovering Microsoft addict blog.  Also of interest is the Forums on the softiesonrails.com site. 

I actually thought about switching my blog engine over to Mephisto to get a little taste of Rails, however, since I'm hosting this on a Windows box the thought was short lived.

I can't wait for the next CTP of Orcas to drop since it supposed to have feature parity with the ancient May 2006 LINQ Preview I'm still using.

• Mike has a nice post where he looks to Deconstruct LINQ.  I often find posts like Mike's, where the author is letting what they've learned flow out in a post, the most beneficial.
• Alex is considering a couple implementations of IQueryable, which he is calling LINQ to Web, that sound very useful.  I've been thinking about writing an implementation of LINQ to Google or LINQ to Live Search myself.  I have a feeling that a bunch of what Alex is after in LINQ to DOM could be handled with a couple extensions on top of LINQ to XML.
• There is a new video on Channel 9 with Anders Hejlsberg, Herb Sutter, Erik Meijer, Brian Beckman that is bound to be full of interesting topics.  I've been having some iPod video troubles lately and can't seem to find a good WMV to iPod Video Converter that runs on a Mac.  I should probably just do the video conversion in Parallels...ok started...can't wait to check it out.