Having just read Why you need to get rid of your freelance developer ASAP, and the comments under it, I can see that people are really clueless about offshoring. It’s a magic box that you put pennies in, and great code comes out a few weeks later!
Having worked for a few companies that sold themselves as “a magic box that you put millions of dollars into, and great code comes out a few weeks later”, I know that this is a serious misconception. Subcontracting is fraught with peril. Offshore subcontracting is fraught with more peril, but it costs less per hour. In both cases, the peril is avoidable, but avoiding it requires that you manage the relationship carefully.
I’ve worked with offshore teams on a couple of occasions, and in one case I was fortunate enough to get sent overseas to work with the team in their own offices. I think I probably have more direct experience with offshoring than most developers or technical project managers, and I’ve seen how offshored projects can go awry, so I thought I’d share some tips for those of you considering offshoring a software project, or those involved with such a situation already.
Continue reading “Tips for Offshoring”
Regarding your article “Awaiting the Day When Everyone Writes Software”:
Your ignorance of the reality of software development would be excusable if not for the fact that your CV suggests that you should know better. Your defamatory description of programmers smears an entire industry of individuals with a single, pejorative stereotype.
Continue reading “Regarding “Awaiting the Day When Everyone Writes Software””
I’m working on a new project which I regard as medium-large in scope, and I’ve decided to use BDUF instead of RAD on it. This is of course heresy in light of the effect XP and Ruby on Rails have had on the web startup zeitgeist. (“Isn’t it all about RAD these days?”) But I still think I’m making the right call here.
Continue reading “Rapid Application Development vs. Big Design Up Front”
Joel Spolsky does a good job of describing why “there is no silver bullet” is true.
When you’re starting a software project, you have to make some technology choices. You have to pick a technology stack, but you also have to pick the tools that your team will use to manage code, track issues, write specs, and collaborate over long distances, among other things.
Some of these things are more important than others, but they all matter. If the majority of the team is using PowerBooks but the UI specs are all done in Visio, that’s going to be annoying. If you’re working on something involving trade secrets (or national security), using AIM is probably a bad choice. But whether you do page wireframe drawings in PowerPoint or OmniGraffle on those PowerBooks, or whether you use IRC or Jabber over a secure connection for collaboration, is less important.
Continue reading “Choosing Your Battles in Software Architecture”