Developing .NET applications very rapidly

In my current position as an agile .NET dude at d60, I have already found myself in need of rapidly building several small applications and services from scratch.

This way of working reminds me a lot about some of the things that Dan North talked about in his “From months to minutes – upping the stakes” talk at GOTO Aarhus 2010.

In the talk, Dan described how he was part of a team that would rapidly prototype and deliver working systems to some stock exchange or something, and in doing this they would often start from scratch and replace the existing applications, instead of adapting old ones. The advantage is that you get to take some shortcuts when you’re making fairly short-lived applications, you don’t have to carry the burden of old legacy crap, you get to re-do, possibly undo(?) almost every decision some time, and you become really good at building stuff from scratch!

So, this is cool, and I think he said a lot of things that really make sense. But how can you build stuff very rapidly when you’re a .NET developer in a Microsoft shop, and your customer has based everything on Microsoft technology? You would think that a .NET developer would be slow compared to the hip coders working with Node.js, Clojure and [insert hip new technology here]…?

Well, it just so happens that .NET developers are actually pretty lucky in that regard. In this post, I’d just like to go through a few of the things that enable us to deliver stuff really quickly, both .NET and not-necessarily-.NET-things.

Git and GitHub

Like all sensible coding teams, we have moved to distributed source control. We have some pretty skilled Git-people among our developers, so Git was the natural choice. And since we’re not really interested in maintaining our own servers, it makes the most sense to have some hosted Git repositories somewhere – and for that, we got a company account at GitHub, because it’s a great place to host Git repositories.

Git’s branching model is just so extremely fast and lightweight that I’m wondering how I ever managed to get anything done in Subversion. Well, I guess I just didn’t update & commit that often then.

Is anyone still using Subversion? Why?


We have our own locally hosted TeamCity server to check out our code from GitHub, build it, run tests, create NuGet packages etc. Configuring and maintaining TeamCity is really easy compared to CruiseControl.NET, which I used to use – and with the extremely cool feature branch support of TeamCity 7.1, our build server will automatically check out, build, and test my branch if I name it feature-whatever_I_am_working_on when I push it to GitHub!


When you want to build stuff rapidly in .NET, there’s really no way you can ignore NuGet – this is how we get to quickly pull down all of the open source libraries and frameworks that we’re using to build cool stuff.

In addition to the free open source stuff, we also NuGet-pack all of our purchased libraries if they’re not already in a .nupkg. And finally, we pack our own shared libraries as NuGet packages as well (actually, TeamCity does this for us automatically on every successful build…), which is how we distribute shared assemblies like e.g. assemblies with Rebus messages.

NuGet has been really easy and smooth in this regard. I’m sorry that I never tried OpenWrap, though – I’m wondering if anyone is using that, or if everybody has moved to NuGet?

Our own NuGet package repository

In order to reduce the friction with NuGet, we have our own NuGet package repository. is just damn slow, and it doesn’t host all of our 3rd party and home-rolled packages.

At first, we used TeamCity to do this, but the NuGet extension in Visual Studio doesn’t remember your credentials, so you have to constantly punch in your username and password if you’ve enabled authentication. This was just too tedious.

Then we hosted our own stand-alone NuGet Server, which would have been OK if it weren’t for the fact that we’re often working outside of our office, and often on other companies’ VPNs. This doesn’t go well with a privately hosted NuGet server.

But then someone had the crazy idea that we should use DropBox as our NuGet repository! This is as crazy as it is ingenious, because we’re already using DropBox to share documents and stuff, so it didn’t really require anything to just throw all of our NuGet packages into a shared folder… which is what TeamCity also does whenever it has packed up something for us, immediately synchronizing the new package to everyone who’s connected to a network.

This way, we can always get to include our NuGet packages, even when we’re building new stuff on a train with a flaky internet connection. As I said: Crazy, yet ingenious!

Free choice of frameworks and tools

Last, but not least, I think a key to rapidly building stuff is to free developers’ hands so that they can use the tools they like to use best and feel are best for the given task.

It seems many companies are afraid that developers might pollute their applications with questionable libraries and bad decisions, but my feeling is that most developers are totally capable of handling this freedom and will respond with a sense of responsibility and care.


These were a couple of things that I could think of that help us build cool stuff and deliver often. As I may have already insinuated, I’m not sure this way of working would work on large monolithic applications that must live for very long.

But then again, in my experience many systems live for too long because they’ve become too huge, and thus too big and expensive to replace – it is often very healthy for systems to be divided into smaller applications that are well integrated, but each application in itself is fairly small and decoupled and thus doesn’t constitute a huge risk and equally huge endavour to replace.

Just a thought on the MVP program

Today, I read Davy Brions latest post, “Most Valuable Professionals? Give me a break.” I have to admit that I was a little bit saddened by Davy’s experiences with the MVP program and its representatives in Belgium, because my view of the MVP program has almost always been positive.

I know that the program is notorious for its obscure election process, and I followed Rob Eisenberg’s hazzle back in January, yet I am confident that the MVP program is a good thing – because all the MVPs here in Denmark that I know of are genuinely cool people, who are working hard on interesting projects, and who still manage to find time and energy to spread good vibes about technology that widens everybody’s horizon. I simply do not know any MVPs that are not awesome technologists!

Another thing is that I was recently given the MVP award – and I can honestly say that I do NOT scratch Microsoft’s back unmerited in any way!

I am pretty invested in the open source .NET world, and when I give talks, I talk about stuff like Castle Windsor, MongoDB, and NServiceBus. And personally, I am much more an indie-underground-micro-framework-kind-of-guy, than I am an enterprisey blessed-by-Microsoft-kind-of-guy, even though I tend to work in enterprisey environments. I just happen to enjoy working with C# and the .NET stack, both professionally and in my spare time, and I guess that’s what shows when I communicate with people about software development.

What I am saying is this: The fact that I get an MVP award can only be a sign that Microsoft (at least in some regions) actually want to encourage developers to be active and contribute to the .NET communities in various ways, even though they’re not necessarily praising Microsoft at every occasion. I guess Microsoft (still: at least in some regions) realize that active software developers are good for the .NET ecosystem as a whole, and in my eyes that’s what the MVP program is about.

I guess I just wanted to chime in with a positive MVP story 🙂

Frictionless Persistence in .NET with MongoDB is available on Channel 9

Microsoft were cool enough to record my talk at this year’s Goto Cph, even though the talk was on the Cloud and NoSQL track.

You can watch it here.

Afterwards, go check out all the other great presentations – it’s so cool they’ re made available!

Microsoft Office Web Apps usability fail

It’s weird, but it seems Microsoft are often very bad at designing UIs.

One major FAIL in my opinion is their new Office Web Apps. Take a look at the following screenshots:



They show clearly how wrong their new “ribbon” tool bar is – why waste 50 % of the vertical screen real estate on a few clunky buttons? And why oh why would anyone throw in the Windows Live logo + Office Web Apps navigations menus ON TOP OF THE RIBBON?

Take a look at the second screenshot above – tt’s just plain stupid that a single PowerPoint slide cannot fit on a widescreen monitor at a decent zoom level.

That’s just weird.