PHP Web Developer & Photographer | Phoenix, AZ

Developer Theory – 95%’ers

There’s no big secret out there that a large problem that plagues the development community is the “95%-itis”. You’ve probably seen it before – where a developer will go all gung-ho, the project is humming along, until they hit about 95% completion, and then run in to a brick wall.

I’m no stranger to this.

I started thinking about this on my drive to work this morning, and I was trying to come up with a solution. I mean, I’ve hit that wall plenty of times, but what was the common denominator about that project that made it spiral out of control and end up in the shitter? The only thing I could come up with was that I was the single developer on the project.

Now, that doesn’t mean that all projects with one developer are going to go down in flames like that…I’ve seen single developers conquer the world, but I believe that if you have at least a team of two, that will help get around the issue before it becomes an issue.

The theory is that when having at least 2 people on a project (and not 2 alpha-nerds that are butting heads), each one of them, aside from being complete wastes of society, will feel a compelling need to hold up their end of the project, because we all like to show off our skills – even if it means they are only holding up their 95%. The trick is, that if you can find 2 developers with similar but slightly differing talents that can overlap, and thus cover the 100% of the project (this will also give the developers an opportunity to learn something new from each other). You can certainly still control the budget of the project with twice as many people, you would just of course have to split the hours between the 2 developers to do so. Also, by doing that I think, going back to the “not having 2 alpha-nerds” on the team, would allow for a great amount of pinging ideas back and forth – similar to what you get with pair programming – and you should be able to maintain a decent pace if not increase the pace at which you can turn over projects.

Also, you would now have 2 developers at the end of the project that can come in and debug/fix something that may have been broken, because both of them worked on the code. Having a single developer that holds all the knowledge of the code is a bad position to be in – if you have 2 people, your chances of being able to quickly turn around a bug fix increases dramatically.

What do you think? Am I far off? Agree? Disagree?

Comments

  1. uh yeah! The last 5% is probably all the stick tasks put off by aforementioned developer because they are difficult. Maybe a whole new project should be opened up just to do them. Then it won’t look as bad to the management who has one hand on each shoulder breathing down your neck.

Speak Your Mind

*