More Offshoring than Outsourcing in Software Development

Outsourcing is often closely related to offshoring in software development, but you can outsource onshore and you can create offshore subsidiaries. This seems to be the current trend for large occidental organisation that want to profit for lower costs in countries like India, but maintain a high control on the process. However, developers in Europe or North America feel no differences if their Asian “competitor” work for a subsidiary or for another organisation. A recent poll from Methods & Tools wanted to know if applications are developed exclusively inside organisations or if outsourcing software development services are used.

The majority of the 346 respondents were equally split between those that are not using outsourcing and those that use it, partially or completely. Complete outsourcing is done by only 6% of participants. There is a need to keep internal expertise when outsourcing is used. The phenomenon of outsourcing of IT services is well known. An article of McKinsey Quarterly estimated the global market for IT and business process outsourcing to $30 billion. The part of software development in this growing market is less known and discussed. In another recent survey published by the Software & Information Industry Association (SIIA), 60% of the participants were offshoring software development efforts and half of them were doing it with external providers.

Get the complete results of this survey with references on Methods & Tools

Project Management Simpler Life

We all do projects and know their problems. With these Project Management Proverbs compiled and some written by Mike Harding Roberts, you can provide additional philosophy to this activity or at least add some humour in your PowerPoint presentations ;o)

Agility and Discipline Made Easy

The goal of this book is to present good practices for software development that are based on OpenUP and RUP, but independently from these processes. The practices are grouped according to six principles:
* Demonstrate value iteratively
* Focus continuously on quality
* Balance stakeholder priorities
* Collaborate across teams
* Elevate the level of abstraction
* Adapt the process

For each practice, the authors propose a definition, practical advices on how to apply and adopt the practice, related practices and further readings. This material is very practical and contains many references to “real life” situations. The practices are selected from RUP and OpenUP and each chapter has a section devoted to compare the situation in other approaches, mainly XP and Scrum.

This book is full of practical knowledge and I will recommend it to every software developer. The only thing that bothers me is that the authors seemed to be forced to apply the “agile” label on their UP practices, with the implicit assumption that “if it is not waterfall, it is agile” and “if it is not agile it is not good”.

Click here to get more details on this book or buy it on amazon.com

Click here to get more details on this book or buy it on amazon.co.uk

References on the Web:
Eclipse Process Framework Project (EPF)

A Gem About Ruby

When I surf the Web to find articles for my software development articles directory, I discover a lot of very interesting content. Sometimes you find articles that are more than interesting: “Why’s (Poignant) Guide to Ruby” is not just a great Ruby tutorial, it is an artwork ;o) Even if you do not program in Ruby, I would say even if you don’t program, you have to read/watch these pages. May the Joy be with you;o)

The Limits of Cost Cutting

Excerpt from: Stanley Bing, “The 0% Solution”, Fortune, Europe Edition, December 18, 2006

News comes from the Department of Labor that productivity growth in nonfarm business in the U.S. hit a critical number in the third quarter. That number was zero, as in naught, as in nothing, no growth at all, not even something you could round up to a minuscule decimal of some kind. [...]

Let’s look at what forces are coming together to suppress productivity growth, to see if we can augment them in some way. [...]

Second, I’m thinking that the reason we kept being more productive in the first place wasn’t so good. When I started out, my department had 20 people rushing around working very hard. Then the corporation, under pressure from Wall Street to grow our stock price every day, decided to do what analysts, investment bankers, and business reporters all agree is the most terrific thing a successful enterprise can do: fire a bunch of people and make those who remain do the work that used to be done by others. Before long, we had ten people doing the work of 20. This naturally produced impressive gains in individual productivity. Of course it did! But at what cost, I ask you. Actually, I’m not asking you, I’m telling you. A big one.
The things that’s happened now is that corporate America is just about done firing people, because if management wants to fire any more people, it’s going to have to start firing itself. That’s expensive. Firing an executive is often more expensive than retaining him.[...]