Most of us like to go out for an Indian or a Chinese meal. Still, deep down we know that home cooking is usually healthier and better for us, and ultimately a lot more cost-effective.
The time has come for UK organisations to start applying similar reasoning when they develop software.
You're probably aware of the opportunities for software development to be 'offshored'; meaning that the job of developing and writing the software is outsourced to a software development firm located away from the UK mainland. Offshore development will typically be carried out by a software firm in India, China, or Eastern Europe.
Usually, you don't need to look any further for the reason why the offshoring has taken place than the organisation's balance sheet. Because in theory, but often only in theory, software development carried out somewhere in India, China or Eastern Europe is supposedly cheaper than getting the job done in the UK.
The cost differential is based on nothing more dignified than the fact that software developers in these offshore locations are willing to accept considerably smaller salaries than those paid to their counterparts in the UK and the US.
The precise extent of the cost savings will vary from one location and software developer to the next. Still, the average cost saving may, superficially, mean that the cost of the software developed offshore is only about 25 per cent of the cost of developing the software back home.
In practice, though, cost is just one element of the matrix of business motivation. Focusing on cost only is shortsighted, and may be the very last thing you should be doing if you want your business to succeed to its fullest potential.
The reason why you should look hard at other considerations than mere cost is linked to the reason why Indian or Chinese takeaways are never going to be as nutritious or as good for you as food you cook for yourself at home.
When you cook for yourself you know exactly what you want, exactly what ingredients are in the food, and you know it will be healthy for each member of your family. Haven't we all at some point had the experience of looking forward to an Indian or Chinese takeaway and then, later in the evening, regretted it because we feel a bit queasy?
This is also true of the software that's going to be nourishing your organisation and giving it the energy to win in the competitive struggle for success.
There are serious strategic and tactical disadvantages to offshoring your software development.
You won't get to read about the disadvantages very much, because offshoring is in vogue at present and the software development firms that provide these services have been spending a lot of promotional dollars extolling the benefits of offshoring and incessantly pointing out the cost advantages.
What these firms don't point out is the menu of downsides such as:
1. The problem of preparing the briefing
The biggest drawback with offshoring is the problem of getting absolutely right the briefing that you give to the software developer.
There is little alternative but to give the firm an extraordinarily detailed briefing if you are to have any hope that the job will be done exactly the way you want it to be.
In most cases, the time you must take to prepare this briefing is so extensive that the supposed cost advantages of using the offshore resource will be very much etched away, often completely etched away.
2. The developer's lack of knowledge of your business
We've all used call centres that are located in often absurdly remote foreign locations. I'm not for one moment criticising the integrity, energy and devotion to duty of the people who work in these call centres.
I'm perfectly aware these people work hard and accept all sorts of inconveniences, such as the need to work unsocial hours to harmonize with the United Kingdom time zone.
All the same, isn't there something a tad ridiculous about phoning a call centre to find out, say, the time of a train from your local station to another station five miles away?
Can that person really know about imminent engineering works or that trains aren't running for a few hours because a lorry struck a bridge down the road? The answer is that for all their training and willingness to help to you, they can't possibly know this.
When it comes to software development we're dealing with a much more complex, vital and subtle matter than simply finding out a train time. We're dealing with the technology that is the very life and soul of your organisation's business processes, competitive initiatives and very likely also the motor of your future business development.
3. The 'true cost' factor
There's no denying that salaries of software developers in offshore locations are lower than those back home.
But it's important to focus on the true cost of software development, and in practice this needs to be assessed by looking at the overall cost of getting the job done, rather than by getting preoccupied with the daily fee rate per developer.
When this overall cost is taken into account, the cost advantage of using an offshore developer can often be a lot less than you initially expected.
4. Time differences
Next on the menu is the problem of time differences.
Call centre agents supplying information such as railway timings and bank balances from a remote offshore location don't mind working unsociable hours, but software developers are justifiably proud of being professionals, and may want to work more sociable hours, or may simply not be at their best when working unsocial ones.
So if you have a pressing issue to communicate to them - an important new customer suddenly comes on board, for example, and requires a significant modification to the brief - you will often be limited to communicating this by email to someone who may not be reading the email for a dozen hours or more.
Is this particular relationship the kind of synergy you really want to pursue when developing crucially important software?
5. Problems relating to language and culture
These two menu items are also potentially grave difficulties when you use an offshore software development resource.
Many UK organisations have found language a particular problem when having their software written in China, where English language competence even among trained Chinese linguists is often much less developed than you would expect.
This is partly an inevitable consequence of the great gulf between how the Chinese and English languages express ideas.
The linguistic problem may not seem immediately so serious when dealing with Indian firms. English is not an official language in India, but it is spoken very widely within the country.
But even in India, the understanding of colloquial English is often not as good as one might expect, or as one might need for complex and sophisticated communication over difficult business and software issues.
6. The need for agility
All the above menu items add up to solid grounds for you to avoid making offshore software development an automatic choice.
Grounds for thinking twice about offshoring are particularly strong when you are seeking development of application software that will be at the front end of your business. And this brings me to what is really the most important argument of all against automatically choosing the offshore option.
This has to do with the ever more crucial strategic objective of winning agility for your business. At Charteris we define business agility as 'an organisation's ability to respond rapidly, effectively and cost-efficiently to a significant change in one or more of its markets.'
What is certainly true, and really incontestable, is that in today's competitive and fast-moving world, efficiency alone is not enough.
Organisations need to have in place a really powerful and flexible capacity for responding to these significant changes in their market in a truly timely manner without compromising their cost base and overall efficiency. They need to become, in every sense of the world, an 'agile' enterprise that fulfils the three crucial criteria of:
- making its activities customer-centric;
- deploying integrated intelligence that ensures management throughout the organisation has constant access to the information they really need for understanding what the business is doing and how it is developing;
- optimising the use of the organization's infrastructure for business development.
To compete with maximum vigour, energy, enterprise and cunning in today's highly competitive markets, agility is a prime requirement for all organisations.
In practical terms, the vast majority of organisations are nowhere near being as agile as they really need to be, or indeed, really want to be. All the same, organisations should not berate themselves for this: agility is a difficult thing to achieve and unless your organisation has made conscious efforts to achieve it, the chance of winning agility may not be very high.
What I'm addressing here is not so much the notion of agility as a strategic objective, but rather the question of whether offshoring your software development is really the best way of achieving this agility.
Frankly, it's difficult to see how it can be, because by definition agility requires a fast responsiveness to significant changes. And for any business of any size, the software it deploys is a crucial resource in bestowing this agility on the organisation.
Developing vital competitive software by sending a labyrinthine briefing to an offshore software developer and waiting for the software to come back is unlikely to be the best way to develop software for an organisation that wants to be agile.
An effective solution to the challenge
So what exactly is the best way of developing this kind of software, software that will catapult an organisation into a condition of agility that makes it leaner, fitter and more successful than it has ever been?
One approach to software development that is increasingly offering some of the cost savings of offshoring yet by its very nature provides a closer, more agile linkage between the software developer and the business, is 'model-driven software development' (MDSD).
MDSD has held great promise for many years, which is perhaps why it has for a long time found itself in something of a railway siding or, to continue the food analogy, lost somewhere at the bottom of the back page of the menu. Nowadays, though, MDSD is really starting to come together.
What is removing MDSD from the realm of the obscure, rather academic terminology, into something that deserves to be of real interest to businesses now, is that it is already present in mainstream software development tools from key vendors such as Microsoft and IBM.
So how does MDSD work? Well, the simplest models that anyone is likely to envisage are pictures: diagrams that depict a business process or a piece of business logic that they wish to automate.
It's more than reasonable to ask a vital question: if we can define a whole process diagrammatically why can't we use the key concepts of the diagram to automate the programming of the code?
In fact, you can.
As you might imagine, you still need support from a technologist who understands this particular automation process and can guide the transformation from the business domain to the technical domain.
However, by creating powerful diagram-based tools that allow the people in the business who will actually be using the software, and the technologist, to work more close together, you can avoid many of the pitfalls of offshoring, or even all of them.
In particular, one of the big drawbacks of the traditional approach to composing detailed specifications and passing that across the commercial divide to a supplier to write the software is this: Your specification may be written in terms that are meaningful to your business, but the programming language that the supplier will be using is almost certainly designed to be generic.
It could be used to program a banking system or a shelf planner for a shop. So often, it's this problem that is at the root of the perennial job of software being developed that doesn’t do what it is supposed to do.
One of the most interesting developments in MDSD is the emergence of 'domain specific languages' (DSL). This is a means of defining models themselves so that the programming language ensures that the application you want contains terms that are meaningful to the business.
MDSD provided by consultants working in close proximity to the client may not, at first sight, compete with the cost of an individual programmer in some far-flung corner of the world, but it will reduce the total amount of effort required and so it certainly competes on total cost.
And because the effort is applied within a close working relationship between the client and the supplier that avoids all the problems inherent in arms-lengths relationships, this is a form of home cooking that really makes sense.
Alan Woodward is chief technology officer at the business and information technology consultancy Charteris plc.
