- 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
Thursday, 18 October 2012
Tuesday, 3 July 2012
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.
Wednesday, 30 May 2012
Wednesday, 16 May 2012
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:
- Dev1 adds migration for a new property called Master and pushes the change.
- Dev2 adds migration for AnotherDev property and applies it to the database
- Dev2 pulls Dev1’s changes
- Dev2 tries to run the app and gets an exception.
- Dev2 needs to delete his migration and rollback corresponding changes in the database
- Dev2 applies Dev1’s migration
- Dev2 adds again migration for AnotherDev property
- 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.
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.
Sunday, 6 May 2012
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.
- 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
Tuesday, 20 March 2012
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.