Listen to your developers, do not rush the project

Listen to your developers, do not rush the project

This particular issue is one that we have all faced at one time or another, a higher up wants a project completed and they want it now, regardless. As a freelancer you have quite a bit of control over this situation, as the higher up is your client, and you dictate to them the amount of time it’ll take for you to finish their project. Typically, I work out my estimate, then double that.

As an employee however, you have little or no say over things like this. I know this first hand, as this is something that I have encountered quite recently.

Let me lay out the following events:

  • Director wants Project X in N time
  • Manager agrees
  • Developer 1 is assigned project X
  • Developer 1 notices an inherent flaw in project X with only N / 2 time left
  • Developer 1 proposes another N time to rectify this flaw
  • Developer 1 is seen to be being negative and project X is taken away from him
  • Developer 2 continues with project X and meets the deadline
  • Project X is released to users/clients
  • Time passes and project X breaks
  • Developer 1 is assigned project X to fix
  • Developer 1 quickly identifies that project X is broke, because of the flaw they discovered earlier on
  • Developer 1 then spends N time fixing project X
  • Project X is patched and working
  • There are several problems with these events, and here I will attempt to identify and explain a few.

Firstly, when a flaw is found with a project, the last thing you want to do is unassign that developer and have someone else fix it, especially someone who isn’t aware of the inherent flaw as they didn’t create that part of the project.

Secondly, you do not hold it against a developer for doing their job. When you hire a developer, you do not hire a ‘code monkey’, as in, you do not hire someone to turn your ideas into code, but rather you hire a professional and you expect them to use their expertise and coding abilities to perform the required tasks to the highest of standards.

Thirdly, if you have an important project that must be released to customers as soon as possible, the last thing you want to do, is push said project before all issues have been addressed. Your choice is simple, you either have users wait longer for a robust version of the project, or you push an early broken one, thus damaging the project in the minds of those that experienced the problems.

Waiting that extra time wouldn’t have been such a big issue, as in the end, you waited for that time anyway, because you had no choice. The only difference is now your project has a bad reputation from the start.

Essentially what I’m trying to say, is that sometimes it’s integral to have a project out with a certain deadline, but missing the deadline isn’t always a huge issue, and while it may cause a few problems, it’ll in most cases, prevent even more from happening.