Rubber Chicken

McKinsey Quarterly has an interesting piece on the dynamics of offshoring service jobs (available via CNet). I'm not sure some of the numbers cited are correct (is the hourly wage of software developers in India 10% of the US wage? I've mostly heard higher numbers like 20-25%), but it does layout a case for the economic benefits of offshoring.

I agree with the basic thrust of the article that, in general, we benefit from free trade. However, the problem is that there are winners and losers and the gains and losses are not equally distributed. The many winners benefit just a little and the few losers stand to lose a lot. So, the losers have an incentive to stop trade. This is not a new thing - Adam Smith described this effect well in The Wealth of Nations over 200 years ago. 

The way to counter that pressure, as the McKinsey article points out, is with training programs and severance packages so that the losers are compensated. However, this isn't happening. So, the pressure will build to reverse course on offshoring with the inevitable result that we all suffer. Will the Federal and state govenments get it right? I doubt it. If the job market doesn't improve, prepare for an extremely destructive round of trade restrictions.

Posted by Rob at 12:23 PM | Permalink

Posted by Rob at 09:59 AM | Permalink

I've never used a two monitor system, but this article makes me want to investigate it further. Displays and graphics cards are super cheap these days and if it is really 9% more productive, then it'll pay for itself in weeks.

Posted by Rob at 11:25 AM | Permalink

Although it isn't really new, portal integration is a great idea that is gaining popularity with vendors. One of the best things about it is that it allows application integration without having to deal with data layer integration issues, which are always painful. In addition, it is possible to create kind of a virtual application that wraps together stovepipe apps to better suit a business case. I've been doing some exploration on the new SharePoint services in Microsoft and it is much improved over the previous version and allows flexible integration. Although it isn't right in every situation, portal integration will probably be of increasing importance over the next few years.

Posted by Rob at 01:31 AM | Permalink

I'm somewhat impressed by the relatively recent initiative at Microsoft to propagate patterns and practices to the development community. This isn't a new thing - IBM and Sun have been doing things like this for years, but it is a first for Microsoft. They've always offered some advice on MSDN, but it was scattered and inconsistent. Their current offerings much more consistent and better organized. I've examined two of the offerings the Data Access Application Block and the Exception Management Application Block and they both are useful. They aren't groundbreaking, but good design often isn't.

Posted by Rob at 03:39 AM | Permalink

I did not notice this in the HTTP/1.1 RFC until recently:

13.1.4 Explicit User Agent Warnings

   ...

   If the user has overridden the basic caching mechanisms, the user
   agent SHOULD explicitly indicate to the user whenever this results in
   the display of information that might not meet the server's
   transparency requirements (in particular, if the displayed entity is
   known to be stale). Since the protocol normally allows the user agent
   to determine if responses are stale or not, this indication need only
   be displayed when this actually happens. The indication need not be a
   dialog box; it could be an icon (for example, a picture of a rotting
   fish) or some other indicator.

   If the user has overridden the caching mechanisms in a way that would
   abnormally reduce the effectiveness of caches, the user agent SHOULD
   continually indicate this state to the user (for example, by a
   display of a picture of currency in flames) so that the user does not
   inadvertently consume excess resources or suffer from excessive
   latency.

Posted by Rob at 12:01 PM | Permalink

Totally different businesses, but could you run a software company using the same human resource principles followed by Southwest Airlines? Their practices include:

• hiring for attitudes rather than skills
• emphasizing teamwork rather than hierarchy
• designing positions so that employees can perform several jobs if required
• offering front-line employees latitude to address customer needs without recourse to a supervisor
• rewarding for appropriate behavior economically and emotionally
• encouraging off-the-job bonding among employees

I especially like the first two. Most software companies look for very specific skills, but since things change so rapidly, is that really important? The second one is a no-brainer and is indeed practiced by many leading software companies. Designing flexible positions is more important than you might think - how many development shops have only a few people that can troubleshoot a build? The fourth one is about empowering teams to do the right thing. Might get a little sloppy on projects that require a lot of architectural attention, but would fit right in with eXtreme Programming. Rewarding for good behavior is also a no-brainer and doesn't happen nearly as often as it should. Lastly, encouraging bonding really helps team morale and doesn't take a whole lot of resources or effort.

Posted by Rob at 04:30 AM | Permalink

USA Today had a piece today about how un-hip cities are trying to lure young professionals (available on Yahoo). I'm at the upper-end of the demographic they are talking about (25-34), but I can understand the problem because I have seen both sides. I live in a distinctly non-hip city that has an aging population. I used to live in a very hip city with lots of young people. Although I think that the size of the cities has something to do with it, Seattle has a lot more creative energy per capita. Starting businesses and being active is contagious.

The funny thing about the article was the description of the things that cities are trying to do something about it. I can understand the desire, but that is a very uphill fight. Proably the best things that could be done are indirect. Don't go out and solicit young people to move to your city, but get it on their radar screen by providing something unique and interesting. Strive to become the best city for cycling in the East or something. If nothing else, it gives the city something to rally around or at least argue about.

Above all, you have to provide an innovative economic base. If you can create interesting and challenging jobs, they will come. But I guess that is a chicken-and-egg problem: without young professionals, where are the new businesses going to come from? Without new businesses, where are the young professionals going to come from? If I could solve that problem, I should run for mayor.

Posted by Rob at 04:13 AM | Permalink

Posted by Rob at 03:20 AM | Permalink

Baseline has a good, common-sense article on buy vs. build decisions. Nothing ground breaking here, but the method presented should suit most straightforward analyses. The spreadsheet that they have developed is intended for use with a function point based analysis, but could be adapted to other measures of software size.

p.s. Overall, I'm impressed with Baseline, especially for a free rag. The analysis is usually good and the articles are, for the most part, relevant and useful if you are in a corporate IT or development environment. You do have to sign up to see most of the articles.

Posted by Rob at 10:42 AM | Permalink

The Economist has an article in this week's edition (available from MSI here) that talks about IT spending entering an ice age where companies are assimilating the technology that has been developed during the late 1990s. Obviously, things are not going very well for some of the most prominent names in the bubble (the prime example being Sun). But, even if IT spending stagnates at 4% of GDP for a period of time, is that really stagnation or does it represent getting more with less? Either way, it probably isn't good for those (like me) employed in the IT business but it doesn't seem like a bad thing overall.

Posted by Rob at 02:50 AM | Permalink

First, to get the exception to the rule out of the way, I looked at MSFT. The GAAP revenue numbers from the latest 10-K from MSFT can be found at http://biz.yahoo.com/e/030905/msft10-k.html. I had guessed about a 90/10 product to services split before looking and that looks reasonably close. The only pure services revenue in their reporting is MSN and Business Solutions. Adding in the total of services embedded in the other line items (primarily support and consulting), I came up with a total of $2,840 million. The income split is even more dramatic with MSFT loosing money on their primary services divisions. Of course, MSFT is an exception and not indicative of the software market as a whole.

Next I did a quick survey of a few companies to see what a more typical split would be in different segments. This showed that overall the product to services split is lower than I would have thought for "enterprise" software. The latest COGN 10-Q (http://biz.yahoo.com/e/030711/cogn10-q.html) has a split $57 million product license to $93 million in services. Even if this was a low license sales quarter for them, that is basically a 38/62 split which is lower than I would have thought. Hyperion exhibited almost the same ratio (http://biz.yahoo.com/e/030813/hysl10-k.html) of about a 40/60 split. A quick examination of Oracle and SAP (who's numbers were not as easy to disentangle), implied a similar ratio.

For people selling to smaller businesses and individuals, the split is more tilted to products. This is not surprising. Intuit has a 75/25 split according to their latest 10-K (http://biz.yahoo.com/e/030919/intu10-k.html). This ratio appears to have fallen from about 80/20 in 2001. Adobe claims an even more radical split with a 98/2 ratio (http://biz.yahoo.com/e/030411/adbe10-q.html). I looked at Symantec, but they didn't split it out in the abbreviated 10-Q.

Although this is by no means a comprehensive study of the issue, a 40/60 split seems common for enterprise software with companies that sell to a broader customer base of small business and individuals having a higher ratio. Not surprising, but interesting.

Posted by Rob at 12:57 PM | Permalink

I may be late to the party, but CodeSmith is a pretty darn cool application. CodeSmith is a template-based code generator that has a syntax that looks like ASP.NET but can be used to generate any kind of application code. If you haven't seen it yet, you should definitely check it out. It isn't really a replacement for generics in C#, but it can help out with the same class of problems.

Posted by Rob at 02:31 AM | Permalink