RayooTech – IT Outsourcing

Even among people as logical and rational as software developers, you should never underestimate the power of myth. Some programmers will believe what they choose to believe against all better judgment.

The classic example is the popular fallacy that you can speed up a software project by adding more developers. Frederick P. Brooks debunked this theory in 1975, in his now-seminal book of essays, "The Mythical Man-Month."

Brooks’ central premise was that adding more developers to a late software project won’t make it go faster. On the contrary, they’ll delay it further. If this is true, he argued, much of the other conventional wisdom about software project management was actually wrong.

Some of Brooks’ examples seem obsolete today, but his premise is still sound. He makes his point cogently and convincingly. Unfortunately, too few developers seem to have taken it to heart. More than 35 years later, mythical thinking still abounds among programmers. We keep making the same mistakes.

The real shame is that, in many cases, our elders pointed out our errors years ago, if only we would pay attention. Here are just a few examples of modern-day programming myths, many of which are actually new takes on age-old fallacies.

Programming myth No. 1: Offshoring produces software faster and cheaper

These days, no one in their right mind thinks of launching a major software project without an offshoring strategy. All of the big software vendors do it. Silicon Valley venture capitalists insist on it. It’s a no-brainer — or so the service providers would have you believe.

It sounds logical. By off-loading coding work to developing economies, software firms can hire more programmers for less. That means they can finish their projects in less time and with smaller budgets.

But hold on! This is a classic example of the Mythical Man-Month fallacy. We know that throwing more bodies at a software project won’t help it ship sooner or cost less — quite the opposite. Going overseas only makes matters worse.

According to Brooks, "Adding people to a software project increases the total effort necessary in three ways: the work and disruption of repartitioning itself, training new people, and added intercommunication."

Let’s assume that the effort required for repartitioning and training is the same for outsourced projects as for homegrown ones (a dangerous assumption). The communication effort required for outsourcing is much higher. Language, culture, and time-zone differences add overhead. Worse, offshore development teams are often prone to high turnover rates, so communication rarely improves over time.

Little wonder there’s no shortage of offshoring horror stories. Outsourcers who promise more than they deliver are a recurring theme. When deadlines slip and clients are forced to finish the work in-house, any putative cost savings disappear.

Offshoring isn’t magic. In fact, it’s hard to get right. If an outsourcer promises to solve all of your problems for nothing, maintain a healthy skepticism. That free lunch could end up costing more than you bargained for.

Programming myth No. 2: Good coders work long hours

We all know the stereotype. In popular culture, programmers stay up late into the night, coding. Pizza boxes and energy-drink cans litter their desks. They work weekends; indeed, they seldom go home.

There’s some truth to this caricature. In a recent analysis of National Health Interview Survey data, programming tied for the fifth most sleep-deprived profession. Long hours are particularly endemic in the video game industry, where developers must endure "crunch time" as deadlines approach.

But it doesn’t have to be that way. There’s plenty of evidence to suggest that long hours don’t increase productivity. In fact, crunch time may hurt more than it helps.

There’s nothing wrong with putting in extra effort. Fred Brooks praises "running faster than necessary, moving sooner than necessary, trying harder than necessary." But he also warns against confusing effort with progress.

More often than not, Brooks says, software projects run late due to chronic schedule slippage, not catastrophes. Maybe the initial estimates were unrealistic. Maybe the project milestones were fuzzy and poorly defined. Or maybe they changed midstream when the client added requirements or requested new features.

Either way, the result is the same. As the little delays add up, programmers are forced into crisis mode, but their extra efforts are spent chasing goals that can no longer be reached. As the project schedule slips further, so does morale.

Some programmers might be content to work until they drop, but most have families, friends, and personal lives, like everyone else. They’d be happy to leave the office when everyone else does. So instead of praising coders for working long hours, concentrate on figuring out why they have to — and how it can stop. They’ll appreciate it far more than free pizza, guaranteed.

Read More:

http://www.pcworld.com/businesscenter/article/254286/7_

programming_myths_busted.html