Thursday, August 21, 2003

Offshore and education funding

I've tried to stay away from the offshore issue since my Aug 4 blog, but this article asks:
Dammit, weren't our kids supposed to bring home the bacon? ... expensively educated middle-class kids learn that their investment (and, in the US, this can be upwards of $120,000 per child) has gone offshore.
Um, no. Higher education costs a fortune, yes, but that is more about the higher cost structure in the US (real estate, health care, litigation, etc) than about any extra value returned. And kids enter university here in much worse shape than those from other countries because of chronic underfunding of grade and high school. Folks, the US is being outinvested in $ adjusted to local economic conditions. Why would anyone think the knowledge (read: IT or programming) jobs should stay here?

The article goes on to wonder if this will be a political issue. No doubt it will, but I have no faith that the public and politicians will attack the problem at its root (funding and cost structure) when it will be easier to stump about protectionism and big bad corporations. Somehow I think adding value is a better product strategy than increasing cost.

IBM shedding PWC?

The Register reports that in the last quarter IBM has quietly shed half as many global services folk as it acquired through the PWC acquisition. No mention of other quarters. So, was the acquisition only about killing a competitor?

Monday, August 4, 2003

Does open source drive IT offshore?

Since I wrote on remoteness a few days ago, new articles and blogs keep popping up.

Chad Dickerson has just linked the moving of IT offshore with open source, in the August 4 issue of Infoworld. To hear him tell it, a pro-open-source IT fellow was bemoaning the move of IT jobs offshore, and wondered at where he could find a competitive US-staffed supplier.


This ties into Alan Williamson's well-read blog on the economics of open source, and the thread over at Simon Phipps' blog.


Chad  ends up wondering to what extent IT's pursuit of overhead in decisions to use open source (eg. Linux) instead of a commercial server operating system is driving all the margin out of software, and driving our suppliers (or their employees) offshore.

"IT managers make these kinds of decisions every day to save money, but it’s the same basic line of reasoning that drives American IT jobs offshore. The cost of running a business should be as low as possible, and any reduction in IT costs (including labor) helps the bottom line."
Difficult questions. Open source solves some problems really well (read: development process), but in relying on open source for deployments do we run the risk of becoming {fishery,steel,...} workers?

And eventually, per the Dilbert cartoon, there is no place 'offshore' enough. I mean, what happens when you keep squeezing margin out? Where does the continuous search for cheaper cost structure drive you?



1. a reader left...
Tuesday, 5 August 2003 6:26 am
 
Well, the flaw in the logic is: Why should IT companies not move offshore? If no open source competitors exist, they can reduce their costs anyway and become more competitve against their commercial non-OS competitors. Either way IT jobs are moved offshore.

Stephan Schmidt
2. a reader left...
Tuesday, 5 August 2003 8:34 am
 
The majority of IT staff do not do software product development. Therefore, the deflationary effects of open source do not affect them. For the minority of software developers working in the software industry, its added pressure however the benefits of reuse allow for higher level of products to be develop faster.
Furthermore, software development is not analagous to marketing. Microsoft w/c makes over 32B a year only hires 50,000 employees worldwide. That's a drop in the bucket in the overall picture of employment.
At best Open source destroys markets, but in now way does it push a move to go offshore. If you don't have a market, doesn't matter how low cost your labor is.

Carlos E. Perez
3. a reader left...
Tuesday, 5 August 2003 8:38 am
 
Sorry about the typos... should have read:

The majority of IT staff do not do software product development. Therefore, the deflationary effects of open source do not affect them. For the minority of software developers working in the software industry, its added pressure however the benefits of reuse allow for higher level of products to be develop faster.
Furthermore, software development is not analagous to MANUFACTURING. Microsoft w/c makes over 32B a year only hires 50,000 employees worldwide. That's a drop in the bucket in the overall picture of employment.

At best Open source destroys markets, but in NO way does it push a move to go offshore. If you don't have a market, doesn't matter how low cost your labor is.

Carlos

Wednesday, July 23, 2003

Remoteness, productivity and web services

While my blogs here are mine, and not my employer's, and are always quite independent, this one is even more so.  And I'm not even certain I have an opinion yet on this topic, I'm just kinda thinking out loud. Ok?

I was reading an article in the Economist, "New Georgraphy of the IT Industry" (for which I don't have a URL, sorry), talking about cost savings in moving tech workers offshore (eg. to India).  The way the article lays it out, the workers and their local infrastructure in India cost about 25% of those in Silicon Valley, and even after factoring in the additional remote infrastructure costs (telecoms and data connections) there is a saving of around 30% on loaded labour costs.

But there are additional costs that aren't addressed by this article, nor in any other source I've read.

A small additional cost is some amount of international travel for business folks bidding jobs, and leads of the teams that eventually do the work.

But more significant is that while all discussions focus on labour and infrastructure cost (savings), little appears on productivity. Agreeing for sake of argument that remote and local personnel are equally productive individually (since if they weren't that would be a different sort of problem), what about the direct impact of remoteness on team productivity?

My own experience is mixed on the subject.  I've been involved in a handful of projects over the past 15 years in which teams were split between local and offshore. But in this very anecdotal sample size of 1, trends (if we can call them that) have emerged:

Offshore works well for extremely well defined projects or portions, where they can run full speed with few remote consultations.

Offshore works poorly when the project involves any notion of research, as in:
  • we're not precisely sure what the problem is; or
  • how it will be solved; or
  • whether changes for a customer will involve changes to design.
These cases share a requirement for strong team coordination and communication, and that is exactly what is complicated in all cases of remoteness, and more difficult still in cases of several-timezone-remoteness.
This leads to a few minor draft conclusions. One is that, absent unusually well developed communications skills or remote team paradigms, remote (and especially offshore) splits are not particularly appropriate for startups, or for new product teams in established companies.

Another is that remoteness should work better when teams adopt some sort of formal design methodology. This means nailing down interfaces between different subprojects, but it also means thinking through problems more completely early on in the project to codify the design so there is less need for churn later. This worked well in one of the remote projects I've been involved in.

It will be interesting to see, over the next few years, how web services will help or hinder this notion of formalism. On the one hand, they allow that nailing down of interfaces. On another, the mindset surrounding web services is that the interfaces can and will change, but since they self-describe the users of the interfaces can tailor more easily. So perhaps web services as a formalism is really about assisting in the remoteness decouple. Don't know. It'll be interesting to watch things evolve.

For completeness, just because my stream of thought got me to thinking about web services and team productivity via the remote and offshore path (only because I started from the Economist article), doesn't mean remoteness or offshore are necessary to thinking about the two. Quite the opposite, actually. So on reading this, please don't think I'm slamming remote teams - I've worked with several, and those projects have at times been very successful. As have local projects.

I'm quite interested to hear other opinions on the productivity issue, and on whether web services will help this problem. Feel free to comment below, or send me a personal email to glen at glen-martin dot com.


[Comments from my previous blog]


1. a reader left...
Wednesday, 30 July 2003 6:26 pm
> Offshore works well for extremely well defined projects or portions, where they can run full speed with few remote consultations.
I'm thinking Y2K. Go make my 2 digit four digits.

> Offshore works poorly when the project involves any notion of research
Requirements such as go build me a booking or pricing engine are a little more complex and require considerable analysis and communication. I couldn't agree more with your statements.

Jason

Friday, July 18, 2003

Voter apathy

Well, here's a consequence of voter apathy that I certainly didn't expect.

People have been moaning for years that every election seems to have a lower turnout that the last, with judicious nodding at the supposed causes (both candidates are weenies, usually).


But how many non-voters would expect that to force a recall one needs only as many signatures as a fraction of the number who voted last?


In California, a recall is forced if the recall effort can claim only 12% of the number of gubanatorial voters in the last election.  Whose bright idea was that?  If 9% of the voters turn out for an election, around 1% of the electorate could force an expensive recall election process?


It is especially ironic that the main excuse for the Gray Davis recall campaign is the California budget shortfall ...


What bugs me about this is that if 95% of the electorate aren't angry with the incumbent, he can still be recalled. 


While there is some justification for allowing a small percentage of the voters who turn up to elect a governor (I mean, someone has to be governor. right?), it is not the case that a recall is necessary, so why accept small turnouts? Recall elections should probably be based on number of elgible voters, not number who turn out.  If 12% of eligible voters sign the petitions, there is a recall election.  If 51% of the elegible voters turn out and vote for a recall, you're gone.  If a majority of elegible voters either isn't upset enough to turn up to recall you or thinks you're ok, the recall fails.


That is, if a recall shouldn't require a 2/3 majority. I think one of Heinlein's characters said something like this, that it should take a 2/3 vote to pass a law, and 1/3 to rescind it. If a law doesn't seem a really good idea, why have it? And if on reflection it upsets even 1/3 of the population then it is probably not a really good idea.
 
[Comments from my previous blog]

1. Bill left...
Saturday, 12 August 2006 7:11 am
Try this on for size.
You might a well be and illegal alien if you do not vote.
There really is no voter apathy, just angry voters.
Who beleive no one pays attention...

Whither reuse

Does anyone believe in reuse anymore?


I started thinking about it again after the third time I was asked about reuse by a C?O during a briefing, and realised that despite not having got there yet, we are actually getting closer.


For me, reuse began with procedural programming. First with C, then with OO, and now with Web services, reuse proponents have argued that now we're finally going to benefit from software reuse.  Procedural brought functional decomposition, but it turned out that the specific decompositions weren't always useful or long-lived.  Then OO tried to improve decompositions by tying them to real-world objects that seem to have more longevity than bald software artifacts. Finally, web service protocols create patterns for specific kinds of information transfer and for self-description of interfaces.


While these qualities of decomposition, modeling and standard interfaces/self-description are probably necessary to support effective reuse, I suspect that they aren't sufficient.  We're going to have to solve a few more problems.


One is what I call world view. If you and I each break down a problem into some set of domain objects (hopefully benefiting from OO techniques),  will we come up with the same decomposition?  And if we don't, and I implement part of the solution and you another, how shall we integrate the two?  We'll need glue of some form or other, to convert between these different views of reality. We'll have to convert parameters, tweak call semantics ...


A simple example is in purchase orders. If I decompose purchase orders into extended line items (with the line item quantities in the line item, not the PO), and you in non-extended (where the PO refers to a simple product and the PO itself has the count), any integration of our various work must map between
these semantic realities, making reuse incrementally more difficult.


I suggest that effective reuse and integration can only easily occur when the various authors agree on some fundamentals about the problem, like what set of domain objects and methods on those objects would be useful.


There is work happening for some well-known application domains, fostered by associations within those industries.  Right now we are seeing agreements on world view being developed for some specific cases of information transfer, including (at least) supply chain, financial instruments, and so forth.  Eventually there will be more.


Another requirement of reuse is effective directories.  People have been talking about this for some time, but I don't believe we've seen a good enough repository yet.  After all, a directory must permit searching on those agreed-upon domain objects we've just mentioned.  However, the current directories I've heard about don't do this - they are horizontal directories, designed by software geeks who haven't yet grokked the human issue here. IMO.


But the largest problem, which applies equally to web services specifically and to software reuse in general, seems to me to be a legal one.


Web services proponents describe a world in which consuming organisations look up a supplier of the information or service they want in a directory, tailor a call to the published interface, and extract the result from the described report format.  What they don't even attempt to solve is the
problem of the business relationship.


When a consumer wants to do business with a supplier in a business setting, their legal teams do a long dance that involves negotiating contracts, signatures, and so forth.  A similar dance will be required for effective reuse that spans organisations, because the reuser (reprogrammer?) will want indemnification from patent infringements and bugs (say) that the component author is responsible for.


So far I've seen no work in this area, to facilitate automated manufacture of business relationships.  And without this, I think reuse can only ever be a personal thing.

Tuesday, July 1, 2003

Junk spam, or: No thanks, my package is big enough

But my Inbox isn't.

Well, it seemed like a good idea. Email spam is like fax spam, so why not charge the email spammers $500 per incident just as we do for fax?

Pity that a committee of the California legislature killed a bill, SB 12, that would do just this.

So what else to try? I've been using spamassassin for some time, and while it filters out a bunch of crap I still need to spend more time than I care to in turfing junk email.

Spammers of course say this is a free speech issue, but I'm reminded of that quip about freedom of the press belonging to he who owns the [printing] press.

I'm starting to think I should declare my mail server private property and charge these jerks with trespassing.

Or just charging them. I heard of a technique that works with phone solicitors. Keep a record of all calls (call number display can help), and when a new solicitor calls inform him that this is a business line and your business is evaluating telephone solicitation. On a subsequent call just listen as a consumer would, write up a report, and send it to them with a bill for as much as you think your time is worth, perhaps $500. This has apparently succeeded in small clains court, a fact not lost on the solicitors who view being informed that you will do this as somewhat more interesting than even the recent US federal Do Not Call list.

I wonder if this will work for email as well? It'd be a bit more work to track down the sender ... I might have to charge them more for my report.