The June 2008 CACM contains the article "A Risk Profile of Offshore-Outsourced Development Projects"

Since this is a common profile, I thought I'd reproduce the Top 10 Risks. Some of these are universal across all project profiles ("Lack of top management commitment"), but others are definitely more problematic for offshored projects. I've highlighted those I think are notably different. All of these should be addressed in your project planning...

1. Lack of top management commitment
2. Original set of requirements is miscommunicated
3. Language barriers in project communication
4. Inadequate user involvement
5. Lack of offshore project management know-how by client
6. Failure to manage end-user expectations
7. Poor change controls
8. Lack of business known-how by offshore teams
9. Lack of required technical know-how by offshore team
10. Failure to consider all costs

That's not to say that I think the ones I did not highlight are unimportant, it's just that I think you can run into those issues onshore (if you replace "language barriers" with "poor communication skills").

Inadequate user involvement and poor change controls are, I think, more acute risks with offshore-outsourced projects because there's a certain amount of "out of site, out of mind" to these projects. It's not like people are hearing programmers talk around the watercooler or at lunch; offshore projects have a greater risk of 'going dark' for long periods of time. Similarly, with different working hours, different holiday schedules, etc., I think it's considerably more common for offshore work to get off the change-control rails. You really need to do daily check-ins with offshore teams, just like you do with local teams. It's harder and slower than a standup meeting, but I think it's definitely a necessary part of the daily routine.

I have a client who needs a Web-page component that does some photo compositing. Nothing super-fancy, but it needs to be professional, obey some business rules, and do some things dynamically based on static data.

The prototype is in Flash, but is filled with hideous programming -- magic numbers, a big monolithic function, etc. Today, the client said that they would be willing to accept the installed-base problem of Silverlight if I recommended it.

Well... It seems to me: Flash's programming story remains, if not terrible, nothing to write home about. Silverlight's programming story is pretty stellar -- a vast programming base from which I can draw the people to do the business rules and dynamic stuff (i.e., the programming). Flash may be beloved by designers, but for photo-compositing, I don't see a great advantage over WPF / Silverlight.

Am I wrong?

One way or the other, if you're a great Flash programmer or have some experience in Silverlight, I'm hiring... Drop me a line direct at lobrien -at- knowing -dot- net.

Update: "Not fair to compare poorly written Flash to green-field Silverlight" was one comment, but I am not comparing the code, I am comparing the code-creation possibilities (and, to some extent, the ecosystem. I think I want people who see the task as programming, not people who see the task as a design issue). "Try Flex," came a message from Adobe, which is certainly fair -- we have a prototype in Flash, Flex has a better programming story than Flash-the-development-environment, Flash is universal. Still looking for developers, but now I'll throw "Flex developers" into the mix as well...

The Midori coverage from SD Times has gone mainstream, even making the front page of BBC World News this morning. Since I reviewed the technical portions of the documents for the story, I thought I might clarify some things. First, though:

• I have no idea who wrote the document
• I have no idea how SD Times came into possession of the document
• I have no idea when the document was written

For all I know, what I reviewed might have been the musings of some 14-year-old in Novosobirsk. A very technical 14-year-old, but who knows?

Substantively, what I can say is that the documents were quite technical and were quite provocative -- they weren't a retrospective on Singularity that we conflated into a discussion of a future OS. The technicality of the documents actually gave me some pause: the unguarded tone and technical depth made me think "this is a long way from being a press release."

Taking the documents at face value, they laid out a very aggressive, very ambitious, scenario for Midori. By "aggressive" and "ambitious," what I mean is that the author really grabs the bull by the horns and addresses concurrency and legacy head-on. Although there's a lot of talk in the analysis about "how is this going to work with legacy Windows" what's interesting to me, personally, is that the technical path being discussed is not a mealy-mouthed "we have to acknowledge the concurrent era" but rather is a full-throated "we have to reinvent what we talk about when we talk about OS."

What I read was the type of stance that some people don't think happens at Microsoft. I was impressed. ("It's all about concurrency": Larry is impressed. What a surprise.) Was it a deliberately leaked trial balloon? I dunno'.

Via Mike Gunderloy comes this link to the claim that a crossword puzzle app for the iPhone is bringing in the developer $2K per day.

A forthcoming column of mine observes that while Microsoft is still the absolute king of corporate development, Apple has become increasingly appealing for development of retail software.

I am aware of the irony that I talk a lot about software quality and the infrastructure of this blog is... well, I think it's up more often than Twitter! ...

But, yes, I'm aware. The cobbler's children go barefoot, and all that...

Not only am I as old as dirt, I started programming professionally when I was 16. So this may just be me being crotchety. But I perceive that the average quality of the code in today's software projects is going down.

That doesn't mean that software projects today don't have vastly more scope and power than they did in the 1980s: they do. I'm just saying that when I engage with clients nowadays, I brace myself to see "FORTRAN 77 written in X": huge monolithic functions with essentially-global variables, deeply embedded loops, etc. Often, X is a tag-based Web language (PHP, CF, ASP, etc.) but I'm not talking about "tag soup" per se. It's not the particulars of markup and code that bother me, although I do think:

• Tag-based Web languages facilitate imperative, drop-through programming
• Tag-based Web languages are now a common early step on the "path to professional programming"
• Therefore, tag-based Web languages aren't blameless

Although X is often tag-based, I perceive an increase in FORTRAN 77 written in the more mainstream object-oriented languages such as C# and Java. (P.S. Please note that I'm picking on FORTRAN 77; I'm aware that Fortran (no caps!) has evolved into a powerful modern language.)

What do you think: am I just being crotchety or are "kids today" increasing the probability of experiencing really poor code? Take my self-selected, totally unscientific poll:

Update: Guillaume Theorot makes the very fair point that kids "back in the day" probably produced crap, too. I know I did. And coding has always been a young person's job (while those who stay in SD tend to move into management). I would guess that the median age of a person whose job is writing code is 30 or less. So there's a lot of code out there written by people who are still in the first half-dozen years of their professional career. So maybe the phenomenon is just that I had the good fortune to have long periods of my career where I was dealing with people who were significantly more experienced. Hmmm... depressingly logical.

Update 2: Implicit assumption -- FORTRAN 77 in X is not easier / faster to produce than modular code. It may seem to be for the first 100 lines, but these 1,000-line monoliths are inevitably fragile as heck and development has ground to a standstill.

I have a job that is probably about 120 hours total work for a good Flash programmer. By that, I mean I estimate that you could probably do it in about 30 hours, but if you can deliver in 120, everyone is happy.

The only caveat is that you need to be able to write ActionScript that's not an offense to the profession of programming. I don't want to see scaling and positioning with magic numbers:

	var FramePointDistance = ((Number(frame_Point[2])-Number(frame_Point[0])) + 15)/4;
	_root.main.frameMC._xscale = Math.floor((currentFramedistant/146)*100);
	_root.main.frameMC._yscale = Math.floor((currentFramedistant/146)*100);
	
	_root.main.frameMC._x = -(210 - (210 - _root.main.frameMC._width)/2) ;
	//showError(_root.main.frameMC._width +":"+currentFramedistant);
	//_root.main.frameMC._x = -(140 + main.frameMC.pic._width/4) ;_root.main.frameMC._x
	//_root.main.frameMC._y = -(130 + Math.floor(main.frameMC.pic._height/1.5)) ;// 
	_root.main.frameMC._y = -(127 + Math.floor(Number(frame_Point[1]))) ;
	

Drop me a line with salary requirement and availability at lobrien@knowing.net

I know that these little Zoho polls I'm running are totally unscientific, but they are interesting. Only thirteen people have voted on the question "Are corporate SD managers too risk averse or too eager?" but every vote has been "too risk averse."

I'm very surprised by that, because back when I actually did real surveys (at Software Development and Computer Language magazines), managerial eagerness to embrace the latest shiny new toy came across as a real problem. That it's not seen that way by the first baker's dozen of self-selecting developers who happen to read my blog ... well, I just don't know how to take it.

Here's a fun one to make up for all the dry process questions I've been asking: What rewards do you appreciate at software project completion? Money? Vacation? Time to learn?

(If you're reading in an aggregator, poll probably only visible if you jump to the site)

I've been pondering this series of polls I've been running and wrote the following paragraph:

But then I was stuck. In the next paragraph I'd like to be a little more prescriptive. But what do corporate program managers need to hear? Do they need to hear "Hey! Don't go chasing after yet another shiny new toy!" or do they need to hear "Go for it! You can take a little risk on the technology for a prototype or a one-off or an administrative automation tool"?

Of course, I'll try to make both points, but which should I emphasize?

Give your answer in the following poll (which, if you're reading in an aggregator, you probably can't see unless you follow it to my site):