Applying functional programming principles to distributed computing projects
A practitioner's guide to increasing confidence in system correctness
Testing a distributed system can be trying even under the best of circumstances.
There is no magic and the lessons of the past apply just as well today.
Most American IT employees take a dim view of offshore outsourcing. It's considered unpatriotic and it drains valuable intellectual capital and jobs from the United States to destinations such as India or China. Online discussion forums on sites such as isyourjobgoingoffshore.com are headlined with titles such as "How will you cope?" and "Is your career in danger?" A cover story in BusinessWeek magazine a couple of years ago summed up the angst most people suffer when faced with offshoring: "Is your job next?"
Your CIO just summoned you to duty by handing off the decision-making power about whether to outsource next years big development project to rewrite the internal billing system. That's quite a daunting task! How can you possibly begin to decide if outsourcing is the right option for your company? There are a few strategies that you can follow to help you avoid the pitfalls of outsourcing and make informed decisions. Outsourcing is not exclusively a technical issue, but it is a decision that architects or development managers are often best qualified to make because they are in the best position to know what technologies make sense to keep in-house.
A diagnostic to help you measure organizational dysfunction and take action
"When in Rome" doesn't help when your team crosses time zones, and your deadline doesn't.
People around the world can work around the clock on a distributed project, but the real challenge lies in taming the social dynamics.
Why repeat the mistakes of the past if you don't have to?