Peter Hancock has an interesting post about rotating developers from project to project. While I agree with a lot of what he says, I don't think this is always a good thing. Maybe it's because I am coming at it from a consulting point of view, but losing a developer on a team is a tough thing to explain to clients. Not because they don't have faith that we can bring on another solid developer, but because developers gain domain knowledge as they work get into the details of the project.

Clients don't like to lose developers with domain knowledge, especially if it's not their decision. It's nearly impossible to tell a client that you're pulling a key piece of the development team to replace them with a new developer. It just doesn't fly. Yeah, their technical differences may be negligible, but the domain specific knowledge leaves with the first developer.

There's another peice to "hot swapping" developers. Certain people work better together than others. Ideally, this wouldn't be true, but everyone has personalities, and eventually, you'll come across two that conflict. You can force them to work together and say "get over it" but even if they appear to be working together, their productivity is most likely not what it could be. On the other hand, certain developers work better together - they just "get" each other. There's not a lot that needs to be done to communicate between them - they just know what the other one expects. In this case, productivity goes up.

And while I understand the idea of spreading the knowledge around, I think having a more productive team is a worthwhile trade off. I also think that developers can get the knowledge from other teams in other ways - lunch 'n' learns, demos, hallway conversations, etc. Yeah, it's not as in-depth as having them on your team, but most of the time it's enough to pique the interest of a developer. That's how I first got into continuous integration. I'd never been on a project with it before, but I talked to team that did have it (and saw the orb), and decided that it would be a pretty good idea to see what this CI thing was all about. I learned it on my own, rather than bringing someone from that team onto our project.

Had we just brought someone onto our project, they would have set it all up. We would all benefit, but I'm not sure the knowledge transfer would have happened anyway. On the other hand, because I didn't have someone to do it for me, I had to figure it out.

Maybe it has to do with the motivation of the developers. Are they happy where they are at, or are they always striving to learn more? If they're striving to learn more, they will.

Jim reports that SBC Michigan (at least) has discontinued their time service.

That's too bad. I always wanted to call right before 2:00 AM on daylight savings adjustment days and see what the "Time Lady" says. Now, I won't be able to do that!

I knew you can enable multiple checkouts in Visual Sourcesafe, but I didn't know you could do it on a project by project basis.

Well, you can. And the instructions are here. Hat tip goes to Steven Pack.

The .NET Guy mentions what shows he records on his TiVo, and then asks us what's on ours.

When I left home for this week, I was all caught up on TiVo recordings - I watched ER and CSI Friday morning!

Anyway, here's my list. It's not any order - just the order that I remember them in.

1. Extreme Makeover: Home Edition
2. 24 (this season is awesome!)
3. CSI: Miami
4. George Lopez
5. According to Jim
6. CSI: New York
7. CSI
8. ER
9. The Apprentice
10. Crossing Jordan
11. Survivor

There are others, but most are my wife's - if I am around, I'll watch, but if not, then no loss. And there are some I won't even watch, like The Bachelorette or General Hospital.

Anyway, what are you recording?

GotDotNet lost another project to Sourceforge today, as Jim has finished the migration of IISReporter. It's available to download here, and he launched a website dedicated to it.

He said he's gotten over 1900 downloads. Congrats, Jim. That's awesome!

Now he just needs full text rss feeds!

Dave Donaldson posted about ConnectionStrings.com. I've heard of this site before, but can never remember to look there.

I deal with database connection strings all the time. And I'm constantly forgetting how it needs to be written. This would make that much easier.

Ben Reichelt asks an interesting question: How does consulting work?

He asks how you can manage to bring on new clients when old clients are calling for new features, bug fixes, etc.

And in doing so, he hits on exactly why consulting works. Repeat clients is a good thing!

This is just my opinion, so take it with a grain of salt, but the hardest part of consulting isn't the work. It's the sales process. Convincing someone you don't know to spend money on you is a difficult sell. But if you do a great job on an existing client, and they seek you out for more work, then the hardest part of consulting is taken out of the equation.

There's one point that I think he's missing that's causing his confusion, though. That's what's known as the warranty period. Contracts don't gaurantee code to be bug free, and will put a time limit on how long bugs will be fixed. There's also what's known as a customer sign-off, where the customer, at the end of the project, agrees that what was delivered is what was expected to be delivered.

Of course, it's a little different depending on how many people are at the consulting company. A company of one will have a much more difficult time moving on, because they don't have the bandwidth, where as a larger company can afford to divert one person back to the project.

But I still content having clients calling you back is a good thing!

Apparently this weekend was the weekend to filter through your email. Robert Scoble did. So did I.

I wonder if this post from Jason Clarke was motivation for anyone else. I read this, and realized that I used to be a filer. Then life got busy, and I became a piler. I still answered (most) emails, but then left the message in my inbox.

So, on my flight to California, I went from 500+ messages in my inbox to six. Not too bad. Now I just need to keep it up.

Oh. I just read through some of the comments. The first one made me laugh out loud!

Bob Parsons, CEO of GoDaddy, has a nice post about rules that he tries to live by.

He got famous fast, after Fox dropped his second commercial from the Super Bowl after it had already ran once.

My favorite of his rules? Number three - when you're ready to give up, you're closer than you think.

Drew Robbins, a former co-worker, has a very nice post about presentations. 

I particularly like two things in the post about how to prepare. First, take someone else's presentation and look at each slide for 10 seconds, and then present on it. If you can present someone else's material with only 10 seconds review, you can present your own content with much less review.

The second part I found interesting was his statement to plan your first five sentences. He says the audience will form their opinion of you in the first five sentences, so plan those out. From there, know the content and speak naturally.