The finishing switch

Sometimes I get some ideas that are not that much tied to code, but are more about the process of developing website. I still think this is relevant to this blog so that is why I will post them here.

Context

Ad agency or a business where deadlines are tight and project are from 1 month to 2 months long

Problem

When a project is long enough and the pressure is high, the developer (the last worker at the end of the chain) can’t stand looking at his work anymore, gets tired and unmotivated. This is not good for the project and for the individual as he is not happy.

Possible solutions

Here his my idea: if you could start two projects of about the same timeline at the same time, then at some point in time during the projects (about at 75%), you switch the developers from one project to the other. You would probably loose some time because the new developer would need to get accustomed to the new project, but in return you would inject some new energy in the project. The new developer would probably think more about the project than the previous one who would be demotivated and not caring as much anymore.

Why do this on 2 projects at the same time? Because finishing a project is probably not the best part.  If you do a switch, both developers would have started and finished a project so it would be fair for every one. Now, there might not always be 2 projects at the same time of about the same length, so one of my coworkers suggested that you could have this floating finisher developer, that for a little while only finishes projects and after that get puts back into the loop of starting projects. Another possibility would be to hire freelancers to help finish a project, in that case I wouldn’t let the freelancer alone, but it would still instill new energy.

For the 2 options where you are doing this in house, you pretty much need your developers to be very close, code in a similar manner and respect each other (coding knowing that someone else will use your code) so I don’t think this could happen everywhere, but I think the culture of your company should push towards a strong  developer fraternity, anyway.

What do you guys think? Is this possible? Would you see this happening in your company? Is this how you would fix this problem?

,

  1. #1 by Jason Crist - September 14th, 2010 at 13:53

    Wow. No. Sounds horrible. The best part of a project is the beginning, sure. Even the first 80% of that. Nobody wants to work on the last 80% (because that’s how it goes, 80% of the project comes first, the other 20% takes the same amount of time!) The last thing anybody would want to do is to come into the end of a project and cleanup someone elses mess; that’s just mean. And then you loose all kinds of time just figuring out what in the heck is going on.

    Instead, to keep things fresh break the project up into a bunch of little ones. Each one either one or two weeks long. You finish each of those little projects and the next Monday you get to start a Brand New Project! That just builds on the old project you finished last week. But it’s still a new project with new goals and new deadlines.

    Keeping it fresh is important. Jumping ship at the very hardest part of a project; not a good idea. I sure would hate to be that “finisher” developer. Though consultants that are “finisher consultants” sure do get paid well. But that’s because it’s hard and it sucks.

  2. #2 by zedia.net - September 14th, 2010 at 14:26

    I agree with you that the first 80% of a project is the most fun and that is why you would switch two developers from two project so that they would both have started a project. Also it would encourage developer to code a bit better or not just for themselves because they too will be working into someone else’s code.

    I don’t know, on the last two project I did, I had help at the very end and I saw that the new guy was way more motivated, being fresh. It was a really good thing for the project. So I was thinking about ways to do this for every projects.

  3. #3 by Will - September 14th, 2010 at 21:29

    It’s a good idea for projects you’re not liking, but what about the projects you’re loving? Do you want to be pulled off at the last minute?

    While I’m sure working with other ‘equal’ developers would be nice, but in my experience there is a range of skill levels out there and giving a project to someone with skills less than your own on the last 20% sounds like bad news.

  4. #4 by FreshDaddy - September 27th, 2010 at 09:43

    Why does everyone use the word “lose” wrong? It’s lose, not loose. Please, if you are going to post an editorial, use correct grammar.

  5. #5 by FreshDaddy - September 27th, 2010 at 09:53

    This doesn’t seem very right to me. I’ve had to look over other programmers’ code, and while some may be okay to work with, most is complete garbage. Programmers’ don’t really understand the concept of programming as if other people are going to be reading your work. In an office setting, there are going to be many occasions where someone will have to try to decipher your code, so make it as easy as possible to read. As far as switching people on a project just to wrap up the other person’s, you’re going to lose a monumental amount of time doing this. On a two month project, maybe the last couple weeks are spent wrapping it up, but if you handed it off to another programmer, those two weeks could easily turn into a month. It’s easy to recall what you were thinking when you coded something, but it may not be as easy to someone else. Code Complete (http://www.amazon.com/Code-Complete-Practical-Handbook-Construction/dp/0735619670/ref=sr_1_1?s=gateway&ie=UTF8&qid=1285595530&sr=8-1) really changed the way I code, and being a relatively new programmer, it gave me a big boost compared other employees in my office. I think all programmers who plan to work with others really need to check this book out.

(will not be published)
Subscribe to comments feed
  1. No trackbacks yet.