I recently moved arei.net to a new hosting solution.  a Little more monthly cost for a whole lot more stability and experience.  So far I am pleased and the migration could not have been easier.  Plus, the new hosting company lets me do other domains without blinking.  So all of the other domains I own (arei.me, sosay.us, and more) are now hosted with their own pages. (mind you arei.me is a mirror of arei.net and sosay.us is merely parked, but the point is that I could use them if I wanted to use them.)

Anyway, hope you like the new host and notice the performance upgrades.

Lately I’ve been the subject of what I call developer drift.

Developer Drift is the process by which an unchallenged developer slowly moves from one project to the next. The project may be in house or external or something completely fabricated by the developer’s mind, but it basically means a developer is less interested in the current project than the project over the horizon. It’s the “Grass is always greener” truism made concrete in software engineering.

For me, this has taken the form of the fact that our customer wants really boring user interfaces which I can crank out like they are nothing. Problem is, I almost never crank them out, because they are meaningless and I never feel challenged/creative by them. (For me challenged=creative.) So I take forever to implement them and tend to make a lot of excuses on why this is taking so long. I feel justified in why it takes so long in the fact that when I am challenged, I really do crank out the code at an extraordinary rate which borders on the obscene when compared to average developers. I’m very prolific when I want to be.

The same thing was true when I was back in college studying English Literature. I could crank out a paper that I found interesting in no time flat, but assign me something that was pedantic and I’d sooner rip my own teeth out with a spoon (“because it will hurt more”).

So the real question I’m trying to find an answer to is “How do you deal with developer drift?” How do you stop people from losing interest when they are bored because the project has become boring? A project I used to work on is suffering from this very problem… they want to keep the team together, but the more boring stuff they do, the less likely they are to be able to keep the team together? Is there a way for this project to challenge it’s developers at the same time as doing boring things? Would contests or “feats of skill” help keep things from getting stale? Or should they just accept this as the life cycle of the developer, assume that people are going to drift away, and prepare for the next generation?

You tell me… how does your project deal with developer drift?

I love the sentiment of this opening paragraph, regardless of the rest of the article…

‘There’s a saying I love: “a camel is a horse designed by committee.” A variation is “a volvo is a porsche designed by committee.” Some of the best product advice I’ve ever heard goes something like “damn what the users want, charge towards your dream.” All of these statements are, of course, saying the same thing. When there are too many cooks in the kitchen all you get is a mess. And when too many people have product input, you’ve got lots of features but no soul.’

(Cut from http://techcrunch.com/2010/05/12/diggs-biggest-problem-are-its-users-and-their-constant-opinions-on-things/ )