Quick overview of TFS Preview

I spent last week playing with shiny/new Web technologies and I needed a place where I could store my todo list and keep my code. I could’ve used Git + Trello but I wanted to give TFS Preview a try so I created a project there, converted my todo list into user stories and connected my repo with my Azure account for automated deployments. After a week of using TFS Preview this is what I’ve learnt:

• It was very easy to configure automated deployments to Azure
• The performance of web portal ranged from acceptable to painfully slow.
• The UI is decent and it’s easy to execute all the basic tasks like add user story, add bug, look up a build
• Burndown chart worked out of the box
• Scrum board is simple and does the job
• Builds would take up to couple of minutes to start even if the build queue was empty
• Total build time was a bit unpredictable, ranged from 60s to 160s for the same code.
• Adding support for nUnit was more hassle than I anticipated
• Story boarding in PowerPoint is not integrated with TFS so you can’t push files directly from PowerPoint to TFS
• There is no Wiki
• Build log is as “useful” as it was in TFS 2010

All in all it is a decent start and I hope that Brian Harry’s team will keep deploying often so every week will welcome us with something new.

Update

You actually can specify how many builds you want to keep. For some reason when I clicked on the number of builds to preserve it didn't change from a label into a drop down list.

Cloudcast show: the clouds are different down under

A few weeks ago I was a guest on the Uhuru podcast where I talked to Micheal Surkan about my experience with deploying to the Cloud and using Cloud based service providers. The discussion was focused on risks associated with using the Cloud and techniques to mitigate them.

You can listen to it here. It’s only 10 minutes :). Enjoy.

Less\Sass done right in .NET

These are the slides and code from the talk I gave last Tuesday at the Sydney Alt.Net. You can grab both of them as a zip file from here. Enjoy!

Entity Framework migrations don't support parallel development

EF migrations borrowed a lot of ideas from Ruby on Rails migrations and this a good thing. The bad thing is that EF treats database as the source of truth. Unpleasant side effect of this approach is that only one developer can work on database changes at a time.
It seems that every time EF creates a DB migration it stores some kind hash of the current database schema which is then used before to the migration is actually executed to make sure that the database is in the right state. This breaks down very quickly when more than 1 developer works on the model. Sample scenario:

1. Dev1 adds migration for a new property called Master  and pushes the change.
2. Dev2 adds migration for AnotherDev property and applies it to the database
3. Dev2 pulls Dev1’s changes
4. Dev2 tries to run the app and gets an exception.
5. Dev2 needs to delete his migration and rollback corresponding changes in the database
6. Dev2 applies Dev1’s migration
7. Dev2 adds again migration for AnotherDev property
8. Dev2 is ready to push his changes unless someone else introduced a new migration in the meantime. In such case Dev2 goes back to step number 4.

I’ve put together a simple app on GitHub that reflects this flow. Each commit is meant to represent a single step.
EF has a chance to become a decent ORM with even better tooling but before this happens EF team needs to understand that developers know what they do and prefer to have more than less rope at their disposal.
I’m happy with the product to be safe by default but there should be a way of disabling those annoying limitations. Without this ability Scott Hanselman idea of LEGO size building blocks is….well just an idea when it comes to EF.

Quick IO performance test of VirtualBox, Parallels and VMware

I’ve been using VirtualBox for over a year and I’m pretty happy with it but I wanted to see if new releases of VMware and Parallels can give me even better IO performance. This is a very simple and coarse test but it clearly indicates that I should give VMware a try.

Test setup:

• Guest: Windows 7 64bit SP1
• Guest: 8 CPUs and 4GB of RAM
• Guest: Vendor specific additions installed
• VMware: Workstation 8.0.3
• Parallels: Workstation 6.0.13950
• VirtualBox: 4.1.12
• CrystalDiskMark 3.0.1c was run 3 times for each app + host

Good enough software

So the first question is what “good enough software” actually means? My current definition is rather simple: whatever makes the business owner happy. I didn’t mention any technical characteristics on purpose because business very often neither cares nor understands them.
Doesn’t it mean that we are doomed to low quality, crappy software that we can’t possibly be proud of? I don’t think so. I’m yet to see healthy, profitable business that thinks its IT delivers features too fast. And quality is a must have when you want to achieve sustainable, high velocity.
The fact that a team can complete tasks quickly doesn’t mean they work on the right tasks. As software engineers we are perfectionists and this is great but at the same time it means that we can become very easily victims of gold plating. To make sure this happens as rarely as possible (I don’t think this can be fully prevented :) ) we need to make sure that every significant activity is driven by the business. It goes without saying that having a prioritised back log is a must have nowadays. But then there are other, smaller tasks that very often are not driven by the business though they should.
One of them is bug fixing. It’s the business that should decide if a particular bug is worth fixing or not. This might be hard to digest for developers and QAs but it is the business that pays our salaries and it should decide what we work on. Our job is to make sure the business is aware of the trade-offs and in this way can make informed decisions. Same logic applies to Definition of Done, build versus buy and so on.
As a side effect of getting the business involved in the process of building software by IT we have a good chance to establish trust between those two which unfortunately is not very common.
Companies rely more and more on IT because it’s the best way to achieve their goals. But we have to keep in mind that if they find a better way they will switch away from IT in no time. So let’s make sure we stay No.1 as long as possible by building good enough instead of perfect software.