See Schrage in CIO magazine on March 15 http://www.cio.com/archive/031506/schrage.html?page=1.
When we outsource of offshore some coding, what are we saying is valuable?
We're saying that the net effect of the installed software has value. We're saying that no existing product does what our new software will do.
We're also saying that the capture of institutional knowledge isn't very important. Yes, business analysts capture the knowledge in words and specifications. But the code -- the final result of the programming effort, the delivered software -- is the real captured knowledge that we're going to commit ourselves to using every day.
So the knowledge capture is of no value, therefore we can outsource it.
Worse, we're saying that the COBOL language is so valuable that we must perpetuate it.
Tools, too. We're also saying that the tools and technologies for programming are an onerous burden on our people. If the languages and tools are such a burden, perhaps we're missing something.
My experiences with customers who outsource is limited to the "outsource the commodity COBOL" variety. Looking at Schrage's article, I finally saw the contradiction. The COBOL is burdensome, but we can't eliminate the COBOL. Since we have to perpetuate it, we'll have it perpetuated by someone else.
Why do we have to perpetuate COBOL programming? Is it because our programmers only have COBOL as their principle skill?
Hold the Phone. Let's review this slowly and carefully. Here's the problem: It's too expensive to produce COBOL programs. Just so we're clear, the issue is the cost of COBOL. The solution appears to be "do COBOL more cheaply", not "do something else that is inherently cheaper." Why the focus on doing COBOL cheaply?
Do we farm out COBOL because we love the language? Is it the only tool that works? That's the hidden message in the value proposition: that COBOL is essential, and rather than do anything new or different, we'll locate someone who can make COBOL for us at a lower price.
And, in case you know people who are outsourcing Java, you can simply cut and paste "Java" in place of "COBOL". The argument is the same: the code is simultaneously of no value and critical to success.
Changing Tacks . Why can't we switch to a higher-powered language? If I had a language that requires 1/2 the lines of code of COBOL, it would be 1/2 the price to create and proportionately cheaper to maintain. If I could do this without engaging off-shore resources, wouldn't that cut management overhead? The institutional knowledge capture (the activity that really matters) could be handled by a simple, fact-to-face, user-analyst-programmer team.
Why can't we do this? Because even though we hate COBOL -- really we hate the price and process of building COBOL programs -- COBOL is as essential as death and tax-law. It appears to be the result of some kind of dogmatic article of faith: COBOL is the only language my people understand.
Or, phrased another way, my people are too intellectually impaired to do programming other than COBOL. And, of course, my people are too expensive to do COBOL programming. So, we must do COBOL and we can't do COBOL.
Which Language? I think the reason we can't abandon COBOL is that we wouldn't know what to do next. With a legacy of COBOL, and a non-technical CIO (or CTO), language choice isn't on the table. We can slowly evolve to Java or C#, claiming it as a "strategic" direction for new projects, meanwhile continuing to build upgrades and extensions to existing software in COBOL.
Rather than a tidy, small, AIX/Linux Python application, we have to buy special-purpose tools, write extensive specifications, send the work offshore, and then complain that it is late, expensive and relatively shoddy.
Is Python really better? If by "better", we mean cheaper to produce, then Python has many advantages. First, it has extensive and sophisticated libraries and frameworks. Also, the language is more compact. For silly demo programs http://www.csis.ul.ie/cobol/examples/Accept/Multiplier.htm, the Python is 1/2 the size of COBOL. For serious programs, the Python can be even smaller. Of course, there are some things that are very hard to express in COBOL, but are quite simple in Python.
Yes, Python is new. Yes, it is open source. More importantly, however, it captures corporate knowledge every bit as well as COBOL, and you can create Python more simply using your existing on-shore, in-house, skilled resources.
What Do You Value? If you value the business solution, then existing products and open source will usually solve your problem faster and more cheaply than offshoring the development of new software. However, you may have something unique that requires unique software.
Since you are creating new software, you value capturing corporate knowledge. If this isn't true, then you are creating software as a hobby, and offshoring your hobby makes no sense at all.
Since you value capturing corporate knowledge, then you have to value the process of capturing and the people who are doing the capture. It only makes sense to give them powerful tools that capture knowledge in a compact and usable form.