Eapen thomas's Library tagged launch →  View Popular

Here is an interesting post on how programmers in the US (and other developed countries) can make a living in the face of the “offshoring” phenomena.

My take on this? I agree with pretty much everything thats said here. However, Ted’s example of a “location-specific attribute” comes from the data center administrator’s side, and not from a software programmer’s side, so I thought I’ll give a software-specific example.

I was talking to one of our customers recently, and he made a comment that went something to this effect: “Business rules Technology is great for any CIO looking to outsource development”. His reasons were:

1. With business rules, there is a clean separation of the technology and the business in an IT system.

2. Outsourcing development, i.e., hooking up the service / business logic / user interface to the underlying database, etc. is a well-known process - essentially, this is technology development - companies ranging from IBM to Infosys have perfected the art.

3. The problems with outsourcing were always related to the incorporation of the business into the IT system - requirements gathering & analysis, several stages of testing, etc. were all geared towards ensuring that the system enforced business policies as required.

4. Business rules technology makes this simple, since the logic is visible, and quickly changeable.

5. Therefore, business rules technology is going to cut down on the effort required to validate / verify what the offshore team has delivered, and reduce the time required to go live with the new system.

6. Exactly the same logic applies to any changes that need to be made once the system goes live.

So why should software programmers not fear offshoring? Simply, someone will always be required to sit in the US and verify what the offshore team has delivered.

No matter how user-friendly business rules technology gets, developers will be required at some point in the business rules lifecycle - for example, when marrying the rules to the underlying business data model. Therefore, developers will always be required to verify the delivery of a business module to the customer. And said developer will need to be in the US - since the business sits there, and verification is best done when the developer can discuss the findings face-to-face. Its all about human contact, trust, and familiarity.

Of course, a lot of current programmers are going to be unhappy about this - testing has always been perceived to be a “child of a lesser mind” in the software development process.

Think about this, though… When C was first invented, the “real” programmers [the assembler brigade] probably scoffed at the C programmers… and, personally, I’ve seen exactly the same thing happen when Java came about - the “real” programmers [by then, it was the C++ brigade] scoffed at the Java guys [”if you cannot manage your memory yourself,…”].

Programmers in the future [at least in the US and other developed countries] will need to become more of functionality experts, and less of semi-colon typists. So what?

Both approaches have been used
successfully. The SW-CMM Level 5
organizations have the data to prove
that they can deliver projects on time
and within budget. It has been reported
that variation between the actual cost
and schedule to the estimated cost and
schedule for projects performed by
these organizations is usually within 3
percent [14]. Even Level 3 organizations
have benefited dramatically from SWCMM.
For example, John Vu of The
Boeing Company has provided statistics
that demonstrated variation of labor
hours went from historical figures
(Levels 1 and 2) of +20 percent to -145
percent to a Level 3 variance of +20 percent
to -20 percent [15]. He also provided
data to show that simply implementing a
formal review and inspection procedure
caused an increase of design effort by
four percent and a decrease of rework
by 31 percent. That change represents a
cost benefit ratio of 1:7.75 - almost an
order of magnitude.

Corporate presidents have discussed
the benefits of LSS in terms of profit
added to the bottom line. For example,
at the 1999 Annual Meeting of General
Electric, Jack Welch said that the Six
Sigma effort at GE had already saved
$3.5 billion beyond their investment of
$1 billion, and they were just at the knee
of the curve [16].

The process improvement approach of
Six Sigma is partitioned into five phases:
define, measure, analyze, improve,
and control. Having defined an existing
process in the first phase, the next
phase is to measure its performance.
Performance measurements of
throughput and quality are taken.
Throughput is the number of items
produced, services rendered, etc. Wait
time and cues are also measured.
Quality is expressed statistically as the
process mean and variation. The cost of
each step of the process is measured in
terms of currency, time, and resources.
The physical layout between process
stages is measured to determine wait
time and cost, or transportation
expense between stages.

Various analyses are then performed,
which include defect analysis
(for example, cause and effect or fishbone
charts) and analysis of variance.
Simulations based on experiments'
design are performed to determine candidate
improvements. During the
improvement phase, a prototype or initial
improvement is made and measured.
The results are compared with the
simulation results to validate the
improvement before it is implemented
for the process. The improvement is
implemented as an operational change
in a controlled manner while measurements
are taken to validate the prototype
results. Measurement is a way of
life in Six Sigma.