Archive for November, 2010

The perils of outsourcing software development

Monday, November 29th, 2010

I’m frequently asked for my opinion on outsourcing software projects and components and in the vast majority of cases I always end up explaining my distaste for outsourcing when you work in the software industry. It just doesn’t work very well at all.

People often decide that outsourcing could be a great idea for a specific project because they see an opportunity to bring something to market very quickly and don’t want to disrupt their existing development resource or interrupt on-going project work. Unfortunately, this decision is often based around the fundamental mistruth that “outsourcing, on a sufficiently small scale, is both cheap and quick and as such harmless.”

The train of thought that leads people to outsourcing is often derailed by a quick experiment in discovering what your company is really about and what your company really does. I have one rule:

“Never outsource your core competences or anything that leads to your competitive advantage”

It’s that simple. If you outsource something that gives your business a real competitive advantage, there is absolutely nothing to stop any or all of your competitors doing exactly the same thing. In this scenario, the only people that win are the agencies that produce the outsourced software.

I’ve mentioned this to people in the past who have been surprised by what they were about to do, and just hadn’t identified the product they were about to outsource as a competitive advantage. What this really highlighted to me was how people often struggle to identify what their company is really about and what their core competencies and products really are. Effectively what the “essence” of the company is and what the product really is.

A little experiment that I encourage people to do, is to take what you perceive your “core” product to be and then mentally remove everything else from your business in a “virtual outsourcing” thought experiment. Take what’s left, the nucleus of your product and look at it’s characteristics. Those characteristics are what your company is really about, and like it or not, if you attempt to outsource any of those core characteristics, you are deciding to side-line your own creative advantage.

This experiment is especially good at highlighting when a company’s’ core asset is technology or a technology product, while they perceive themselves to be more of a media company or non-tech company. If your core product is technology, you are a technology company regardless of whether that’s what you set out to be. This often applies to online business’ who fail to grasp that if their product is a website, you can never take the technology away, and at it’s very core, that is the value proposition of their business.

Understanding your core competency is not the only place that outsourcing and software development fall apart, it just illustrates how businesses reach these conclusions in the first place. The original software outsourcing model was a natural evolution of the idea that software development process could be modelled after manufacturing in some sort of glorified “software assets” process where you built a bunch of components that just plugged together to make a system. This idea rode on the back of the general good practice of reuse in software development and the boom in “4GL” programmer-less languages in the 90s. Well, that fad never really worked out, but it took people awhile to realise that the core assumption that software is like manufacturing was fundamentally flawed.

“Software isn’t a manufacturing process, it’s a design process, and as such, should not be outsourced as if it were mass production or duplication”

Outsourcing the manufacture of plastic cups works really well. We all know what a cup looks like, and even if you make a particularly fancy cup, you’ll get your designers to come up with the patterns, you’ll ship your pattern to a manufacturing plant who specialise in duplicating plastics and you’ll ask them to make a few thousand. Which part of producing a few thousand of your plastic fancy cups was the important part? The design that you handed over that made your cup different to the others was the important part, not the duplication. Software works in exactly the same way.

When software was first offshored, there was this fundamental misunderstanding that the development of the software was akin to pressing CDs in a plant, or manufacturing a thousand cups, when actually it was more like when Apple make products “Designed in California”. They’re produced en mass in China, but that’s not the important part, the design is. Treating the design of your software as if it were replication will only ensure low quality of the resulting product.

If you’re attempting to outsource components of a bigger system, you’re also going to face a whole second set of problems all related to trying to make your outsourced components consistent and maintainable in the context of a greater software product. You’re likely to receive software that’s outside of any “house-style” in your code (with different conventions), the quality will be unmonitored and variable and you’ll find it very difficult to prescribe patterns, practices and QA processes. Once you’ve dealt with that collection of known unknowns, you’ll then have to integrate the outsource components into the system with nothing more than a contract in place to ensure that they work. Don’t let that contract fool you though, it’s not security, it just means you’re allowed to get mad when the software doesn’t work. You’re not going to get your wasted time back. Despite the best quotes and claims of third parties, never underestimate the effort of integration. I worked on a particular project which touted a “4 hour” integration process. All things considered, with 3 days of meetings and the trailing two weeks of implementation, it took roughly 300x the quoted length of time.

People are often driven to outsourcing as a way to circumvent resource restriction but all that happens when this is attempted is you fall foul of the traps highlighted by Fred Brooks in The Mythical Man-Month – namely, the communication overhead of coordinating outsourcing and your internal development and the effort that it requires vastly outweighs any perceived benefits of the outsourcing exercise to start with. This is all compounded by the fact that humans are notoriously bad at writing software specifications, and your best attempt at outsourcing is only as good as your best attempt at communicating your ideas in way that the other party thoroughly understands. But as soon as you specify succinctly, you loose any kind of adaptability and end up, in the best case, with the product you thought you needed at the start of the process, rather than the product you know you need by the end because of changing business requirements.

Rework in conjunction with outsourcing is difficult and costly and if you end up down that route, you’re going to want to avoid it at all costs, though, ironically, if the outsourcing venture is successful, you’re likely to want to bring the project in house anyway to curb high maintenance costs and loosing your competitive advantage. Maintaining outsourced software is expensive for a very obvious reason: agency culture dictates that they must charge an appropriate amount to offset their risk of having no work. Bringing outsourced or offshored projects back in house is going to cause you yet more problems, especially if your technology stack doesn’t exactly match that of the outsourcing partner. That great PHP system they wrote? Doesn’t work so well with your ASP.NET software or your Ruby on Rails app. You’re then faced with the horrible position of having to re-write to bring the software back in house,
or maintain a whole separate set of systems to support this product, raising it’s total cost of ownership significantly. This might not be a problem if you make hybrid technology choices deliberately, but at this point they’re effectively forced upon you.

So is outsourcing ever a good idea? Well, probably not, all things considered. You’re more likely to get more consistent results by spending the money you’d allocated for that killer new outsourced project training your staff. In the long run it’s better value. It’s also sometimes more prudent to skip what you perceive to be that “killer opportunity” when you don’t have time or resource and revisit it later with a quality product that maintains your own creative vision and competitive advantage. There are a few well established large agencies with a known track record for delivery and professionalism. You’ll find these agencies are more likely to work alongside you and your staff, rather than dropping a boxed product on your lap, and this co-working gives them a distinct advantage over any other form of outsourcing as they are more likely to work well inside of your internal processes.

If you’re considering outsourcing a software project, you should always ensure that you factor the effort required to bring that project back in house as part of the estimate of cost. If you’re considering outsourcing part or all of your core product, you’ve probably already lost.

Pluralization (Pluralisation!) in C#

Monday, November 15th, 2010

So today at work we were spitting some league table-ish (shh! unreleased feature!) data onto a screen and I realised I was going to have to manually pluralise “0 donations”, “1 donation”, “2 donations” depending on the number of donations having been made. I felt a little bit of the crazy eye coming on, because I’ve solved this problem a hundred times before.

By “solved” I mean, “I’ve written a shitty if(..) statement to solve this problem a hundred times before”, which totally sucks.  And I exclaimed “but surely this is a problem everybody that has ever displayed text has faced, it can’t possibly be that we all solve this every day”.

Turns out, that this has pretty much been the case until recently. Rails has Pluralize methods, and most ORMs clearly have this functionality to some extent but I’d never happened across a general purpose .NET library to do the job.  After sitting and expressing my utter disbelieve that this isn’t (at least in it’s simplest form) a solved problem, I actually used some GoogleFu to discover that it was.

So, in .NET4, it looks like Microsoft actually got round to implementing this in the framework, I’d not happened across it before, but it’s pretty freaking cool.

So let me introduce, if I may, the System.Data.Entity.Design.PluralizationServices namespace!

The more observant of you might notice that it appears to be in a namespace with “Entity” in the title. I suspect it was cooked up as part of EF (boo! hiss!) but luckily, you don’t need to actually reference the main System.Data.Entity assembly as it’s been separated out into a satellite assembly.  It also looks like localization is hiding behind one giant NotImplementedException(); currently, but the usage is pretty simple and calmed me down in no time.

var _pluralizationService = PluralizationService.CreateService(Thread.CurrentThread.CurrentCulture);
var plural = _pluralizationService.Pluralize(singular);

and that’s it!

Almost too good to be true, but it actually works, managing “donation”=>”donations”, “sheep”=>”sheep” and as esoterically pointed out on twitter, even “cardex”=>”cardecies”. Which is really pretty cool.

We took it a little further and added support to it in our suite of extension methods for the ASP.NET MVC HtmlHelper class, so in our MVC views we can do this:

<%@ Import Namespace="Extensions" %>
<%=Html.Language().CorrectTenseForQuantity(Model.Quantity, "word") %>

Which I thought was pretty tasty (and at the very least, gives us the same thing the Rails guys have, just with slightly more explicit syntax (my personal preference).

I’ve put our extension implementation up as a Gist on GitHub here if anyone wants to see the full implementation.

Pretty cool.