Skip to main content


Showing posts from December, 2012

Looking forward to 2013

First and foremost, the biggest change in 2013 is that I will be responsible for and managing the development team. To help the team with the challenges we will face in 2013 I will need to stay hand on too, so that should make time management critical just to make sure I can personally fit it all in. This will probably be the biggest challenge I have faced in the last few years and something that I'm looking forward to getting started with.Another change for 2013 will be refining our agile process. For the 2nd half of 2012 we followed a scrum methodology, successfully developing and deploying an MVC replacement for an old ASP legacy application. Feedback from the technical teams resulted in us modifying the process, removing task hour estimation from the sprint planning session with no measurable negative effect. Additional feedback from the business indicated that sprints were causing some friction when defining stories and planning releases. The 6-9 month development cycles…

Review of 2012

2012 has been a full-on year with lots of change. I started the year in my previous role, preparing for a transition into a newly created role of "Solution Architect"; moving away from both day to day coding and purely concentrating on .NET applications / systems. It sounded a really interesting challenge but another opportunity presented itself working for my current company in another newly created role of "Technical Team Lead". It was a hands-on development role, leading a team of 3 developers bringing a large business critical application in-house and helping to roll out scrum and other processes (such as TDD/BDD, Continuous Integration, etc.) to the business and team.The very first challenge was the knowledge transfer sessions for the "out-sourced" application, which had been designed and developed by one company and then the maintenance passed onto a second company. It's probably fair to say that the code has grown organically rather than bei…

VS2012 does not support Silverlight 3.0

Not sure that this post really needs anything more than the title. If you are upgrading a Silverlight project from VS2008 or VS2010 be aware that VS2012 only supports versions 4 & 5 of Silverlight. If you need to update the solution / projects to use them in VS2012 I'd recommend upgrading to at least Silverlight 4 first in your existing Visual Studio and then once it's working upgrade the solution/projects to VS2012 so you're only tackling one set of issues at a time.

Upgrading a TeamCity build from VS2008 to VS2012 and using NuGet

We've recently upgraded to Visual Studio 2012 from VS2008 and switched over to using NuGet rather than direct project references for our third party tools. Everything worked as planned until we checked the solution into source control and the personal build for TeamCity kicked off. Almost straight away the build fell over with the following error message:D:\TeamCity\buildAgent\work\e6ae794aab32547b\.nuget\nuget.targets(102, 9): error MSB4067: The element <ParameterGroup> beneath element <UsingTask> is unrecognized. Project BJ.Core.sln failed. Our projects were still targeting .NET 3.5 but to fix the problem we needed to update the visual studio version in the build configurationNote: we were are using Visual Studio 2012, but our Team City server is currently hosted on a 2003 Server O/S instance so we must select the VS2010 option in our build configuration (VS2012 option only works on 2008 Server and higher due to .NET 4.5 limitation).

Can't target .NET 3.5 after upgrading a Visual Studio 2008 solution to 2012

I ran into an interesting problem today when upgrading a visual studio 2008 project to visual studio 2012, whilst trying to leave the targeted framework to .NET 3.5. Each time I tried to open the solution all my test projects automatically upgraded to .NET 4.0 regardless of what I did. It was impossible to downgrade the project using either the project property page or manually editing the project file. I'd make the change and then reload the project, a project conversion report would be shown and the project was back to targeting 4.0 again.After a little more digging around I noticed that it was only my test projects that were doing this, all the other class libraries, etc. were perfectly happy targeting 3.5. After a little more experimentation I isolated this to the project type guids section, if I removed this from the project definition then I could re-target my unit test project at v3.5 and everything was happy. Note: As the linked blog post indicates, you might lose the…

Agile Delivery Experiences

I'm now in my second role in which I've had chance to introduce agile working practices to the team. In both roles the projects and applications developed under scrum have been successfully shipped and accepted by the business. The success of the deliveries has been measured by:Functionality: The early visibility the business gained through the end of sprint demonstrations made sure that all the functionality the team developed stayed on track and provided exactly what the business wanted. There were no nasty surprises once the final code was shipped!On Time: It is generally agreed that you can only have two of the following: quality, functionality and/or a "business set" ship date. The hardest lesson for a business to learn is that if it wants a set amount of functionality by a set ship date, then the only thing that can be modified by the team to meet the expectations is quality. Luckily in both instances everyone agreed that quality shouldn't be compromise…

Do "Task Hours" add anything in Scrum (Agile)?

What do task hours add to the overall process in scrum?This was a question that has arisen from all team members in both instances that I've helped teams switch over to scrum. The benefits of artifacts like the comparative story point estimation, the 2 week sprints, stand-ups and the end of sprint demo have been self evident to the team, but as one I think every team member has expressed dismay when it comes to task planning and estimating each task in hours. Left unchecked there is a natural tendency for people to actually begin to dread the start of each sprint purely due to the task planning session.In my current role we've been lucky to investigate this further as a team.The team sat down to discuss the problems it was experiencing with estimating tasks in hours and the following common themes appeared:It is hard: Maybe it shouldn't be, but time estimation is hard! Story points are comparative and abstracted making them easier to determine, but time estimate is gen…