The awesome team at Brisbane-based mobile developer CodeHeroes recently released a manual for offshore development. This is a great read and covers a lot of important ground for people that are interested in whether or not they'll get better outcomes when getting software development done overseas.
As the digital revolution continues, more of our world is moving into software. Companies aren't just buying word processors and spreadsheet applications - they're looking to streamline their work processes, provide improved automation, increase the efficiency of their work force, all ultimately to improve their bottom line.
Well, that's what they should be doing. Sadly, at a lot of companies it's still business as usual.
Part of that reason is because getting custom software created can be really expensive, and that's before you even figure out what software you need, what it should do, who is going to use it, how it's going to work - and who is going to make it. Then after going through all that - assuming it all works - you have to deploy in within your organisation and then get everyone to use it. Then you have to maintain it to ensure it's kept up-to-date so it's secure, reliable, and keeping pace with your business.
If you're just thinking about how much things cost - which, as we can see from the above, is just a small piece of the puzzle - outsourcing offshore can seem like a great idea. Especially when you talk to a local developer and find out what you want to do is going to cost thousands of dollars, or tens of thousands, or even hundreds of thousands. Yikes!
I won't go into a lot of detail about the pros and cons of offshoring - the CodeHeroes manual does a great job of that, so please read that. However, there's a few things that I think are worth adding to the discussion for companies that are looking to get custom software built.
The Evidence
The discussion of whether or not offshoring is good or bad is generally based on anecdotes. Most people reference individual stories - from their friends, from colleagues, from random postings on the Internet. It's pretty easy to cherry pick any number of these stories and build a compelling case that outsourcing is bad, or that outsourcing is good.
The truth, of course, is that like almost anything remotely complicated ever in the history of anything, it can't really be simplified into just two sides. Experiences with outsourcing range all the way along the scale from bad to good - some people end up having a great experience, getting the software they wanted on time and under budget. Some people end up getting what they want, but it took much longer and ended up costing more than expected. And of course, some people end up with nothing except bad memories and a hole in their pocket. But there's a lot of room in between.
Even when systematic attempts are made by academics to study offshoring, the results can be conflicting. One study notes:
While the potential cost savings for companies from offshoring appear impressive, our research suggests that companies are leaving billions of dollars behind when they offshore.
MIT's prestigious Sloan School of Management is more positive, noting that "offshore outsourcing can deliver on its promises, but it takes a tremendous amount of detailed management on both the client and the supplier sides".
These formal studies have gone some way into identifying the factors that influence how an offshoring project can be affected. If you're a giant company with the resources to spend the time to understand and address all those factors then you'll probably be ahead of the game. Maybe.
The practical upshot of all this is that if you're new to the world of software development and you're trying to get something done - it's basically impossible to know whether or not offshoring will save you money or not.
What are your deliverables? More importantly, have they been delivered?
The CodeHeroes article identifies a bunch of common mistakes; they're a good reference point and if you can deal with them then you're on the way to minimising your risk. However, for web-based projects, there's one item that I think deserves special emphasis, because it's something that non-technical people might not grasp immediately - or realise why it's important - the source code.
The source code is the weird technical gibberish that actually makes your software do anything. If you're getting a website built, it's pretty normal that you'd have a copy of the source code of that website, and for other software applications (like a mobile app), to really own the intellectual property behind that app, you need the source code.
Note that "source code" typically means the actual code - the programming language bit. Your average website is made up of that as well as a bunch of other stuff - images, databases, CSS. I'm using "source code" as a shorthand for "everything you need to run your entire website".
Until the source code is in your possession, you have not been delivered anything. Without the source code, you'll suffer from a bad case of vendor lock-in, which can have dire effects in the long run.
Here's a harrowing tale from someone who recently posted their experience offshoring a website build. (Yes, it's an anecdote - but it nicely illustrates the issue. How often this happens and how risky it is - that's another story.)
In a nutshell, this person - Miki911 - was paying a developer in India to get a website built. The developer started working on the site and kept Miki911 up to date on progress by sending through links to the the website, so it looked like things were getting done. Money changed hands, but then the developer decided that he wanted more money - and that's where the problem started.
Unfortunately for Miki911, even though a big chunk of the website had been built, he or she hadn't actually received anything as a deliverable - no copy of the source code, no database dumps, nothing. Miki911 had no access to the web server or hosting environment, so couldn't make a copy of it. His project was being held ransom.
This is a tragic story of an unscrupulous operators out there. Not everyone will have a bad experience. But it's really important to note that this scenario could have been easily avoided if Miki911 had known how important having access to the source code at all times was. If the developer had gone rogue, Miki911 could have just picked up where he left off and handed the entire project to someone else - it still would have sucked (changing developers halfway through a project invariably is a giant pain), but it wouldn't have been the total train wreck that it was.
While CodeHeroes do mention that you should be getting deliverables as part of a code review, I think it's really important to highlight what those deliverables should be - because if you don't know what you should be getting, you won't know to make sure you've gotten it.
If I'm offshoring what should I be asking for?
You need to make it clear to your developers that you will be requiring a few things before you engage them. Here's a quick checklist of things you need to make sure you'll be getting - right from the start - of a web project:
(Bear in mind: software project deliverables will vary from project to project.)
- The source code. This could be ASP.NET, C#, PHP, JavaScript, or Java code (or many others, in any number of combinations). The source code should be getting kept in a source control system like GitHub. You should own the GitHub account and your developers should have access to it to put stuff in - that way you can always get it out whenever you want.
- The static assets. Static assets means things that make up bits of your website that aren't actually code. This can include images, logos, fonts, CSS, PDFs, or any number of other digital objects. The good news is these can all also live in GitHub!
- The database. Almost every website is database-driven these days. The database can contain everything from your blog posts to your entire product or customer database. You do not want to lose this. Access to the database can be provided in any number of ways - maybe daily backup dumps, or you might have direct access to some database backend to take snapshots whenever you want. Your website without the database can, in many cases, be just as useless as having nothing at all.
- Ownership of any domain names. Don't let someone register your beloved business name on your behalf, unless you really, really trust them. Someone can hold your website hostage. Buy it yourself and make sure it's in your name.
- Access to the hosting environment. This one is perhaps not so critical, but it's good to have if you can get it. Having access to the environment in which your website is getting developed (or deployed) means you can get in there at any time and take your own snapshots. Optimally, again, you'll "own" the relationship with the hosting provider and your developers will only have access to operate within it. This will help minimise a variety of other risks.
- Intellectual property assignments. This is getting into legal eagle territory - check with your lawyers to understand who owns the intellectual property if you're getting outsourced work done. It would be sad if you had the next Facebook built, and then it turned out that you were snookered by a developer's craft contract that meant he had some ownership you didn't know about.
Any reticence by any developers you're talking to about a project should be considered, at the least, "very alarming".
Now, all of this stuff put together should give you a complete, working copy of your website - think of it like a backup. But as with all backups, it's critically important to test. Without testing you have no idea if what you've been given does what you think. Unfortunately verifying all this works as you'd expect is a complicated process in itself - you might need to talk to another developer for this.
This list isn't exhaustive - there might be other components you should have access to. But hopefully just knowing that there are these bits you need will help you ask the right sort of questions to figure out the full list of things to get.
And a final note: all of these things are important for any form of outsourcing - even if you use a local developer, you want them all.
So, what should I do?
By now you've hopefully accepted the fact that software development is a complicated process. Any custom development of any complexity is going to require a lot of effort. The bigger and more ambitious the project, the more expensive - and riskier it's going to be. Being aware of and understanding the risks is the key to avoiding them.
Offshoring can be a great way to find cheaper developers. You need to manage a lot of risk, and you may end up inadvertently becoming a software development project manager as you orchestrate people around the world.
But is it cheaper? Well, there's no one correct answer.
The best advice I can offer is do some more research to find out what will suit your particular needs better. Read the CodeHeroes guide, talk to people that have offshored development - the success stories and the failures - and talk to local developers. Get a variety of estimates from offshore and onshore options, and compare both the financial aspects as well as the management and risk overheads.
Of course, at Mammoth we're happy to help anyone that wants custom software done. But we recognise we're not the right fit for everyone - we've regretfully turned down potential clients because we didn't think we were the right fit for them. So we invite you to get in touch with us and we'll happily have a conversation with you to help you understand the world of software development and the best way for you to approach it.
