Button Rock Ventures

In May, I had the pleasure of attending JP Boodhoo's Develop With Passion boot camp class. JP's class was favorably mentioned in the acknowledgements section of Scott Millett's Professional ASP.NET Design Patterns book. Checking JP's web site, I saw that a class was coming up here in Denver. Surely it was meant to be. The title of the course, "Develop With Passion", really spoke to me. In fact, when asked on the first day of class why I was attending, I said I wanted to rediscover my passion for writing code.

Drop and Give Me 20 Unit Tests

Ok, maybe the class wasn't quite that intense, but it did live up to its boot camp moniker. The days were scheduled from 9 AM to 9 PM with a couple of days going just a bit longer. For the first two days, we were tasked as individuals with writing the code to get a set of unit tests for a movie library working. This ultimately led to us developing a domain specific language for querying and sorting.  Some of you may be asking "Isn't that what LINQ is for?" You may be right, but one of JP's points was that you need to have the fundamental skills to be able to implement these sorts of things yourself. Use frameworks and tools where they make sense, but don't let them dictate your design or impose artificial constraints.

Despite JP's assertion that we were working on the fundamentals, I found the exercise to be humbling, as I think many others in the class did. Clearly there is a difference between "understanding" concepts such as generics and delegates and truly understanding them at a gut level. Using the framework's built-in generic types or implementing a few basic generics of your own does not lead to true fundamental understanding.

Let's Turn It Up to 11

If the first two days were a little bit humbling, the rest of the week was even more so. Starting on day 3, we pair programmed a web store application including implementing a routing and URL building framework along with an IOC container. No ASP.NET MVC or WebForms here. We were also required to pair up with someone different each day, which I think was a great way to facilitate more interaction between classmates.

The basic rhythm of the exercises was that we would be tasked with either writing the tests or the implementation, with JP doing the other half. Each task was time boxed and then usually JP would pull the code of the first team to finish which we walked through and refactored as a group exercise. Then we would all pull down the refactored code and continue on to the next exercise. This process was made really elegant by using the Git DVCS.

Doing test driven development (and perhaps more accurately, test driven design) was definitely a mental shift for me. JP's ability to really decompose a large problem into smaller problems using OO design principles and patterns was impressive. Whenever I thought he was done decomposing a problem he always seemed to demonstrate how a problem could be broken down further. The project really drove home the point that I have a lot to learn when it comes to OO design. I'd be willing to wager that most, if not all, of my classmates felt the same way. I agree with classmate Mike Murray's take that this shows a big weakness in our education system and industry. As an industry and as individuals, we can do a lot better.

The Real Takeaway

While a lot of time was spent writing code, I think the real value in the course came from JP's tips and tricks for being a better developer and person. I don't think anyone could walk away from the class being a master of OO design. Instead, I believe we are now equipped with practices for continuing our individual journeys of learning and improvement.

Some of the biggest tips I learned from JP include:

• Set measurable and specific personal and professional goals. I think a lot of us know this, but how many of us actually do it?
• Master your tools and automate as much as possible. Using tools like Resharper and AutoHotkey JP is truly a master of automation. I could probably  count on my fingers how many times he used the mouse during the week. I am now much more cognizant of things that are slowing me down and am focusing more effort on removing the friction.
• Dedicate time to continuous skills development. JP's suggestion is to do a 20 minute Code Kata first thing every day, focusing on a skill or tool that you want to learn.
• Stop worrying about how your skills compare with others. You only need to be better than yourself. Work each day to be a better developer than you were the day before.
• Learn a shell and an editor. I've added learning VIM and PowerShell to my learning plan.
• Stop fretting about work-life balance and instead focus on what you're doing right now. Work when you're at work. If you can be better focused at work, you'll be better able to leave work behind and be present for your family. JP suggested TimeSnapper for monitoring your productivity. I'm evaluating RescueTime to achieve similar results.

The Final Analysis

Would I recommend attending the Develop With Passion course? Absolutely, but as JP said, be prepared to leave your ego at the door.

As I stated on the first day of the course, my goal was to rediscover my passion for software development. Did I walk away from the course having met my goal? Not exactly, but I think that's okay. The passion has to come from within, and I think the course laid a foundation for achieving that through continuous learning and self-improvement. Over time I think that is how you kindle the passion from within. And, ultimately, that's more valuable.

Now that we've explored Distributed Version Control Systems and specifically Mercurial, let's take a look at the different options for deploying your .NET application to the cloud.

In my mind, there are basically three different levels of cloud hosting:

• Level 1: Back when "cloud" was only a meteorological term, there were still options for hosting your application somewhere other than a machine under your desk. These include shared hosting environments, where your application lives side by side with other applications. In a shared hosting environment, you generally don't have access to the operating system and are typically limited to uploading your application to a directory created for you on the shared server. Moving up, you can get a dedicated server (virtual machine or actual physical machine) which affords you complete exclusive access to the operating system and greater capacity. The downside is that you are stuck managing an operating system. When you're busy creating the next world-changing application, who wants to be dealing with infrastructure issues?
   
• Level 2: Now we're getting to the true cloud solutions. At level 2, we have services such as Amazon's EC2. These services allow you to spin up OS instances quickly and easily. Need more capacity? Spin up additional EC2 instances or up-size your existing instances. However, at level 2, you're still dealing with an operating system and its associated maintenance. This might be handy if you need complete control over the OS to do your thing, but the typical Web 2.0 application simply consists of a web application and a database. Why should we need to even think about the OS?
   
• Level 3: Acronym alert! At level 3, we have the Platform as a Service (PaaS) offerings. PaaS solutions provide a place for you to deploy your application while abstracting away the underlying OS. Scale your application by paying for more instances of your application. The beauty is that you don't have to worry or think about the operating system at all. Your application simply lives in the cloud.

In the .NET realm, there are two level 3 options that I'm aware of: Microsoft's Azure and AppHarbor. These two options seem to take two very different approaches. Azure introduces a whole set of API's and technologies for running your application in the cloud. This means you're going to be coding your application to the Azure platform. Does anybody really understand the entire Azure offering? I sure don't. To me it seems needlessly complicated. Just take a look at the features page and the pricing page (compare that to AppHarbor's pricing) and tell me if it makes sense to you. Is the size of the FAQ page a sign that Microsoft has overcomplicated things? The fact that the Azure group is undergoing a re-org tells me that Microsoft realizes they have a problem.

AppHarbor on the other hand, is dead simple. Push your code to a central Git or Mercurial repository and AppHarbor will automatically build and deploy your code. Also, this code can be the same code you have already developed and are running locally. No special API's needed. Sweet. AppHarbor calls themselves "Azure done right". I think they're on to something.

Now that I've spent a couple of posts providing some background on Distributed Version Control Systems and cloud hosting options, I promise that Part 3 will move on to a real world walkthrough of deploying an ASP.NET application using Mercurial and AppHarbor. Stay tuned.

If you spend any time following trends in software development, it's been hard to avoid two topics: Distributed Version Control Systems (DVCS) and Cloud Computing. These topics have been on my "to research" list for quite some time. Recently, I've been reading a lot of good things about AppHarbor, a cloud computing platform for .NET developers which supports both the Git and Mercurial DVCS as repositories for your application's source code. Sounds like a great opportunity to explore both of these topics. In the next few blog posts, I'm going to walk through getting an ASP.NET project into a Mercurial repository and deployed to AppHarbor. To the cloud!

Why Distributed Version Control Systems? What's wrong with Subversion?

Distributed Version Control Systems are hardly new. But if you're like me, Subversion has been getting the job done. Why fix something if it isn't broken? Personally, I've come to the realization that there are two main problems with Subversion:

• Centralized repositories lead to commit-phobia. The adage is to commit early and commit often, right? Well, if you're working on a disruptive change, you might not be in a position to commit working code until you're far along in the process. You don't want to commit non-working code, especially if you're in a continuous integration environment. But if you're not making incremental commits, you might find yourself in a pickle if you need to rollback some changes you've made along the way. One way around this is to create a new branch for your task, which leads me to the next issue.
• Branching and merging is painful. Every time I need to branch and merge in Subversion, I break into a cold sweat. How do I do this again? I find myself looking at the Subversion documentation (again), crossing my fingers, and hoping for the best. This has lead to the avoidance of branching and merging altogether, simply to avoid the mental pain that results. 

A DVCS addresses both of these problems. With a DVCS, you'll have your own local repository that you can commit to as often as you want, without sharing your incomplete changes with others. When the right time comes, you can synchronize your local repository with a central repository to share your changes with others, and get their changes as well.

A DVCS is also much smarter about branching and merging. By dealing with changesets instead of revisions, you'll find the merging process is not as fraught with peril as it is with Subversion. Joel Spolsky does a much better job explaining this in his Hg Init: Mercurial tutorial.

Why Mercurial?

In the DVCS realm, there are two major players, Git and Mercurial. If I were working in a large corporation, the choice between these two systems would probably involve a steering committee, benchmarking, feature matrices, a cost-benefit analysis, etc. Thankfully I can be more agile than that. I found the following pages useful:

• Stack Overflow: What is the difference between Mercurial and Git?
• Git vs. Mercurial: Please relax 

In the end, I chose Mercurial. The command line interface is very similar to Subversion. It strikes me as having better tools on Windows, including TortoiseHG which installs Mercurial and integrates it with Windows Explorer. There is also a Visual Studio source control plug-in for Mercurial called VisualHG. Command line purists may scoff, but I definitely like integrating my source control into Visual Studio. It saves me from switching contexts between Visual Studio and the command line when I want to do a source control operation. TortoiseHG and VisualHG provide a very similar experience to using TortoiseSVN and VisualSVN with Subversion.

In the end, the choice between Git and Mercurial isn't really going to matter. Both are well regarded. Does Git speak to you more? Have at it. AppHarbor supports both Git and Mercurial.

Coming Up Next

So far, I've talked about my goals with this project, given an overview of Distributed Version Control Systems, described how they're an improvement over a centralized system like Subversion, and explained why I chose Mercurial. Up next I'll talk more about cloud computing in the .NET realm and explain why I chose AppHarbor for this project.

The test of a first-rate intelligence is the ability to hold two opposing ideas in mind at the same time and still retain the ability to function.

- F. Scott Fitzgerald

When I first heard this quote many years ago, it really resonated with me. I heard it in the context of being a good leader, but over time, I've come to appreciate that it is equally applicable to being a first-rate developer as well.

Consider two stereotypical developer archetypes:

Coding Cowboy

Coding Cowboy rides into town and dispatches the bad guy (business problem) with speed and efficiency. Unfortunately, the main street storefronts are riddled with bullet holes (technical debt) and the townsfolk are cowering in their houses.

Architecture Astronaut

Architecture Astronaut delivers great results at great cost in terms of time and dollars. Intensive training (design) must be taken before the mission (coding) launches. The end result truly is rocket science, unable to be understood by mere mortals.

A couple of blog posts led to some intense discussions in the .NET community this past week. First, Robert Scoble blogged about MySpace's death spiral and the belief by some insiders that the use of the .NET platform was part of the problem. This was followed by Expensify CEO David Barret's blog post about why they don't hire .NET programmers.

The community reaction was swift and angry. On some level, this is understandable. For better or worse, techies often base a lot of their identity and self-worth on the technologies they use. These arguments even happen on a smaller scale within the communities themselves. Those who have embraced the ASP.NET MVC Framework often look down on those who still are solving problems using ASP.NET Web Forms. Many a SQL Server guru has scoffed at those who dare use Access or Excel to solve a business problem.

What many apparently fail to realize is that these debates are just another iteration of the Bikeshed Effect. As @johnsheehan tweeted, "While you all argue if .NET is some magical panacea that will make or break your startup the next Facebook will just go on building itself."

MySpace didn't fail because of .NET. Comments to Scoble's blog post from MySpace insiders paint a more telling picture about what the real root causes for failure were. Like most projects, the problems were more closely associated with a broken organization: staff turnover, scope creep, a lack of good testing and staging environments, and other general dysfunction. .NET shops don't have any sort of a monopoly on those problems. Similarly, the .NET platform and those that use it aren't somehow flawed when it comes to building a software start-up, as David Barret asserts.

Attend a technical conference and you'll find plenty of sessions on the latest shiny new product feature or the hot new framework that's going to change software development. Those are fun to discuss and learn about, but as professionals, we should be spending more time gaining a better understanding of our customers' industries and the problems they want us to solve for them. As a developer, it's no longer good enough to wait around for a stack of requirements and then go about implementing them. In my mind, the first attribute of a talented developer is that they understand that they are paid to solve their customers' problems, regardless of their choice of tools. As an industry, let's commit to getting better at doing that instead of arguing about what color to paint the bike shed.