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

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.

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.