February 2012 Entries
While I am not a fan of offshoring IT development, I do understand the attraction. From a rate perspective they look very attractive, but in my experience that is the smallest part of the story when it comes to offshore resources. There are a number of hurdles you will have to deal with if you are going use developers that are half way around the world.
The first obstacle is the language and cultural barrier. I am not talking about just understanding the words, but understanding the meaning behind the words. A significant amount of time can be required to make sure that requirements are properly understood. You need to put additional time in your project plan to account for this factor.
The second thing you are going to run into is the time difference. In all cases I have been in both teams have had to adjust their schedules just so they have at least a minimal overlap. Then there is the fact that nothing ever gets done in one day as they would with a team that is entirely in one location. This will stretch your timelines for task completion. This could mean the loss of opportunity costs in situations that require a quick turn around.
Quality is another issue that I have seen in some cases. This is a problem that happens no matter where the work is done, but the distance makes it harder to keep an eye on quality as development progresses. I had one case where a remote team indicated that they were done coding and when we tested it we found it was nothing but stubs. I would hope that this is the exception and not the rule, but it should be a tale of warning. You may need to allow for additional budget for rewrites and/or to interview the offshore team to determine their competency.
These cautions are not to say that you shouldn’t use offshore resource, but that you need to understand the costs related to this approach and if you can afford them. Just as with open source code, there is not free lunch and what you don’t know could kill your project. Make sure you go into these situations with your eyes open.s
del.icio.us Tags: offshore
Recently I have gone through the process of selecting a web hosting company for one of my clients. There are a lot of options out there and a number things you need to be cautious about. I will go over some of the decision points and questions you will want to ask a company before signing a contract.
The first thing you need to do is define the features that make up you site. Is it made up purely of static content or does not use a database? If that is the case then you can choose just about any hosting company that supports your favorite development platform (ASP.NET, PHP, etc.).
If you require a database for your application determining how much control over the database and how much space is required are you next tasks. Many hosting service will offer either MySQL or a limited access SQL Server. This will support small databases with simple CRUD requirements.
If you require full control over the database and need features of the server such as the operating server scheduler you are now looking at leasing a dedicated server. This will significantly increase your cost per month, but once you get to this level it is either a dedicated server or a cloud service such as Azure.
One thing that I have found is that if you are getting a dedicated server from a hosting company often your best bet is to purchase your own SQL Server license instead of paying the monthly charges for the hosting service to provide them. The average I have seen is about $275 per month. Even if you pay $4000 for a license it will pay for itself in just over a year.
In the end there aren’t any easy answers, but hopefully some of the guidelines above can help you find the right solution for your hosting needs.
If you have seen the Windows Phone commercial where the father is in the grocery store with the shopping list in OneNote you have gotten you first taste of the flexibility that can be had with OneNote. I like most consultants have a lot of fires going and once and I am finding that the templates in OneNote are helping me to get a handle on the different projects and tasks I need to track.
I started using OneNote to do simply what its name suggests: take and organize notes. Lately though I am finding ways that it can help to centralize things that I had been using multiple applications to accomplish. Having them all in one place, as with most things makes it easier to not miss something.
You may find using the tasks feature of Outlook works well for you, but I found that I was in and out of my email so fast that I ignored the tasks. As simple To Do List template in OneNote seems to be the solution for me since I spend so much time documenting projects. As an alternative you can use the Prioritized To Do List shown below or the Project To Do List which gives you a list per project.
When starting a project at a new client Project Overview is a great way to organize your thought and make sure that you cover all the essentials. While I am just starting to use it this template is quickly proving its worth.
Of course if you don’t find a template that fits your needs you can create your own templates. Start with one of the standards and edit it. Then click Save Current Page As A Template. This is great especially for customizing templates like the project overview to suit you needs.
There are many other features to this tool for you to explore. Add to everything above that it is a write once, maintain anywhere product and I can easily access my notes from any browser or even my Windows Phone. Life is getting just a little better.
Most of us spend our time in Visual Studio writing .NET code within a Visual Studio solution. Given this situation we find it very easy to integrate with Team Foundation Server for our source control and have a well known work pattern. But what happens when you want to use TFS as source control for non-Microsoft development?
The most important thing to remember is that source control should be as transparent as possible to the developer. If the particular language or product does not have an Integrated Development Environment then having plug-ins to maintain this transparency is not possible and your next concern is making the way the developers interact with TFS as simple as possible.
Let’s assume that you are facing the latter situation. The first thing to do is sit down with the team and find out what their normal process is for developing. You need to find out how the code that becomes their executables are organized. The key is striking a balance between logical separation and making extra work by creating too many projects. If they users are accustomed to managing their code in a single folder then you may want to maintain that same structure for your TFS projects.
Once you get past the structure issues you then need to address the subject of branching and labeling. I recently ran into a situation where the non-Microsoft development was customization of a packaged software. This presented additional considerations. They get a copy of the off the shelf code with each release from the vendor. There may be features that are actually removed from one release to the next. This made it easier to start a new project for each release than using labels or branching. The last thing they wanted was code files creeping back in if they got latest and only new files had been overwritten but the obsolete files were still there.
In the end it boils down to understanding the needs of your development teams and molding your usage models to those needs. Maintain as much transparency for your developers as possible by limiting the touch points for TFS and as often as possible allowing them to continue developing the way the always have.