4 Challenges of Offshoring Your Web Development

Today I had a conversation with a client in which he told me about his frustrations trying to get quality web development done overseas. The lure of ultra low-cost development is definitely powerful and I certainly read plenty of success stories in my business magazines.

So why isn’t it working for my client? Why hasn’t it worked when my company has tried it? I’m not certain I know all of the reasons, but I have a few ideas at this point.

1. Type of project

   It seems like most of the success stories I read involve mid- or large-sized companies who have a web development need that is consistent and predictable (same thing over and over). I am not personally aware of any small companies who’re having great luck with small, one-off projects.

   If a project is sufficiently long to absorb some of the training costs of bringing a foreign team up to speed, I think the odds of success go up. Working on a small project with an overseas team can be pretty inefficient. There isn’t adequate time to work through communication issues, train the developers on the unique nature of your project, etc.

2. Quality of requirements sent

   In defense of programmers everywhere, and specifically those who’re offering overseas outsourcing in this case, most clients give pretty crappy requirements. I’ve seen everything from the proverbial napkin-sketch to a bulleted list of 3 or 4 requirements and been expected to accurately estimate and deliver a finished product from this.

   Whether in or out of the U.S. the amount of detail a programmer needs to do his or her job is always more than a client thinks should be the case.

   The problem is severely exacerbated in overseas development due to the issues inherent in cross-culture, cross-continent communication. My team is exceptional at “interpreting” clients’ requirements but even we find it challenging.

   I believe your odds of success overseas is, in part, related to the quality of the specs you send.

3. Actual quality of work and skills

   This is the one that has me most concerned. I’ve honestly never worked with an offshore developer whose skills matched or exceeded those of my in-house developers. My programmers are better every time. More expensive? Yes, but I believe quality matters too much to accept sub-par work just to save some dough.

   I think there are definitely situations where “good enough” does the job, but our clients are very detail oriented and the quality of our work is crucial to our reputation. Additionally, our clients bring us a very wide variety of projects so we’re often working with new technologies and pushing the limits of our skills. I need developers whose skills are current and who can solve problems they’ve not yet encountered.

   Even with the “simple” stuff we’ve been sorely disappointed. We recently spent a significant amount of time trying to hire a few overseas programmers who could take website design files and slice and program them. We advertised for expert-level programmers and were willing to pay a premium to find them.

   The experts who applied had 2-3 years experience and were mostly Dreamweaver and FrontPage users. Not one of them was capable of writing clean, semantic markup or creating tableless, CSS-based layouts. The discrepancy between the design file we sent and the “finished” website that was delivered was shocking in every case. Not even close.

   I maintain hope that there are actually some high-quality programmers somewhere out there. Maybe some of these skills are just still too new? Maybe the overseas programmers will eventually catch up?

4. Communication

   There probably isn’t much controversy on this subject. Communicating with a team in Asia means being up in the middle of the night. Worse, it means work that needs to be done ASAP isn’t possible and change-orders to a delivered project might take a day or two, due to the time zone differences.

   I’ve read with interest about outsourcing options springing up in Central and South America. Most countries there are within a few hours of any U.S. time zone so this is much more reasonable. I haven’t tried any firms there yet but I’m hopeful that at least the time zone issue can be crossed off the list of problems!

   In addition to the time zone issues, cultural and language barriers also exist. English spoken with an accent over a Skype connection can almost sound like a foreign language.

   Again, for long-term projects or relationships I think communication issues can be resolved.

I’m still holding onto hope that I may have a successful experience at some point, but I’ve also accepted the possibility that the types of projects we do and the level of quality we need may not be achievable.

I’m interested in hearing about your experiences outsourcing to overseas firms. What challenges have you faced? What secrets to success have you discovered?

The Difference Between Big and Small Companies

Roughly speaking, the first half of my software development career was spent in, or consulting for, Fortune 100 companies.

The last couple years I've been working in mostly small companies. Here, in a nutshell, is how I see the difference between the two basic environments:

In a big company it's often hard to figure out who knows the answers to the questions you have.

In a small company, it's obvious who has the answers to the questions you have, but they're too busy on 5 other projects to help you.

My 5 most used free utilities

With Microsoft's release of ProcessMonitor, the next version of SysInternal's FileMon, I thought I'd share the 5 free utilities I use most often in my day to day programming.In no particular order (and I realize there's nothing original in my list):

ReflectorReflector is a "class browser", which pretty much it let's you look inside .NET assemblies and figure out how they work. Recently I used Reflector to uncover a [possible]

threading bug in MySQL Connector/NET. I also looked inside the SynchronizedQueue class to see exactly how it worked (yes, it was obvious but I wanted to make sure).

FiddlerFiddler is an HTTP Proxy aimed at helping you debug HTTP requests. It's particularly useful at Fuel because we work with a lot of different data protocols over HTTP. Of the 5 tools, it's probably the one I'd be most screwed without :)

FileMonFileMon is one of those "last resort" tools - you don't use it often, but when it gets to the point where you need it, it comes in really handy. FileMon monitors file/directory access, so it's great when you think their might be permission issues or missing files.

Snippet CompilerLately I've been using SC less often, but it's still pretty handy. SC is a mini-IDE which lets you quickly compile C#/VB.NET code and run it as a console application. It's great for testing small chunks (snippets) of code.

Visual Source SafeI know a lot of developers hate visual source safe. For the most part I agree with all of you. The truth though is that any source control is better than none (ya ya, not if it corrupts your repository). If you can, consider buying the relatively cheap SourceGear Vault or installing the free Subversion, but we are using VSS here at work and it's doing it's job just fine.
Honorable Mentions

TestDriven.NETI haven't had a lot of opportunity to work with TDD.NET lately (doing a lot of planning/and very small projects). I love tools that enhance VS.NET, and this is the best one if you're into unit testing.

FireFox There are a lot of addons that make FireFox a great tool for web developers. JavaScript console, DOM Inspector, Web Dev Bar.

How to hire a programmer

I'm always a little amazed when I hear of an employer who doesn't give a written test when hiring someone. I know it might take more time and I've often heard how some people don't work well under interview-pressure – but that's just tough luck. I swear to god, we have higher standards when it comes to hiring a juggler for a kid's birthday than when it comes to hiring programmers – I blame talentless managers.

That mini-rant aside, my favorite way to perform interview tests is to write a very basic feature description go over it with the person and ask them to actually code it on a COMPUTER with all the tools you're used to using (specifically, google/the internet, VS.NET, SQL Management Studio, …). I never remember what an SQL Server connection string looks like, and I'm not going to expect someone else to remember.

The type of "feature" I normally ask for is a *very* simple user-management tool where you see a list of users and can edit/add/delete their information (maybe a name, email address and password or something). I'll typically mention that the feature would be part of a larger enterprise application where maintenance is key. The goal is to get to see how they write their code. I'm specifically interested in seeing if they use any N-Tier or OOP concepts and how their codebehind/aspx are done.

I like to give them about 1 hour to work on this and will let them have up to 30 minutes of "do you want a bit more time?" Hopefully we can all agree that 1.5 hours is more than enough.

The first time I used this system we interviewed 7 people who did miserable. My manager (the owner of the company) told me the test was obviously too hard and I needed to adjust it. Luckily, before I had time to do so, we interviewed an 8th person who wrote it in 30 minutes and did better than people who worked on it for 2 hours. We hired him and it was well worth it.

Here are some general recommendations if you do give exams (or want to start) during interviews:

1. Don't make the exam too hard or too long
2. Write it yourself, have other coders on your team do it too, and adjust it accordingly to how well you did
3. ALWAYS let the person know they'll be writing a test prior to the interview and let the person know how long it should take
4. Don't bother giving the exam unless you think the person is a good fit in all the other important categories
5. To expand on point 4, consider doing it as part of a follow up
6. Tell them to fill in any auxiliary parts (like logging) with comments if they want to, and that other comments aren't really necessary
7. Give them full access to all the tools you use, create a blank database for them and give them a username and password that has full access to that database – for security purposes, you might have to adjust your network a bit
8. Let them use the internet and any books you have (you might want to mention to them that they can bring any books they like to the interview for the exam)
9. Treat them like any other employee: don't look at them code more than normal, sit them with your team (if possible)
10. If you use stored procedures, mention that you'd prefer they used stored procedures if possible. If you don't say anything, don't hold it against them for whatever they use.
11. At least 2 or 3 times ask them how it's going, what part they are on and if they are having any difficulty. GIVE THEM the answer to any questions they ask. If you don't know the answer, either tell them they are looking at it wrong or help them look it up. Don't be afraid to sit down and type A BIT for them.
12. Let them know that their time is up and ask if they'd want to spend more time finishing stuff up or reviewing it.

I'm not going to tell you what you should look for or not (since it'll depend on your own personal prefences), but there are some real tell-tell signs as far as I'm concerned:

• Datasets and SqlDataSource are very bad (update: the dataset thing didn't go over too well in the comments ;) )
  
• Data access shouldn't be in the aspx or codebehind
• Objects should be properly disposed of (using either try/finally or usings)
• Check how exceptions are handled: I don't expect anything in the global.asax Application_Error but exception swallowing is also very bad
• Naming convention might not be a big deal, but I hate Hungarian notation
• No hard-coded connection string (or at least a //todo, move to config)
• Caching!
• Parameterized queries for either sprocs or in-line
  

Which way are mobile phone games heading?

Aside online games and static game devices like Playstation, mobile games are the next most popular games around now.
The popularity has grown so big that mobile operators are competing against each other by offering their subscribers loads of both free and paid games for their pleasure. Not only mobile operators, cell phone manufacturers are also pre-programming their phones with a variety of games.



The growing interest in mobile gaming is producing a lot of benefits for the mobile industry. The operators are deriving sizable revenue from selling these games, software developers are regularly deriving royalties from phone manufacturers and the manufacturers themselves are cashing in heavily on revenue from subscribers. You will appreciate the level of income in this are if you consider the fact that by the year 2009, there would be 220 million mobile phone game fans in the world.
Now lets delve into the kinds of games we have around:
We have the embedded games that are factory coded into the phones, SMS games that operate by interacting with a SMS server upon which the game resides and browser games that are played online using the cell phones mini browser. Of all these games the cheapest and most popular is the inbuilt ones though the excitement offered by SMS and online games are not a deterrent to people who would spend every dime to get hooked on. The reason is browser games are of multi-media origin and can be compared to the type experienced on Playstation or xbox.
There are several ways to develop mobile games though the most popular language used are C++, Java and Binary Runtime Environment for Wireless (BREW) platform .
Out of these three, Java is the most popular method. The reason is obvious – java is widely supported by the web and supported by all the principal phone manufacturers. Again a medium like J2ME is open source and thus cheap to use as a development medium.
Java as we know it is highly portable across platforms and leaves developers with little worry that their program will not work on certain phones. Programmers choose this language platform because it does not interfere with programs running natively on the phone.
But in reality the future of mobile game development is in MIDP 2.0 API which is a compilation of high end applications that allow developers to come up with sophiscated and highly interactive games for fans. It is fast to use and ensures a stable program after compilation.
It is projected that this program, though futuristic, shall be the standard for mobile game developers for a long time as it exhibits versatility and the quick deployment – qualities programmer love.