For those in development, there is the pervading sense that you have to perform really well to get ahead and to do that requires very little sleep and lots of time in the office. Traditionally, the game industry has been this way, but more and more software development firms are doing this...to their detriment. It is a well-known fact that very few developers last more than 5 years in the game development industry. The single most common cause for a developer to leave a game development firm is that they are spent, worn out, burned out (whichever term you are familiar with).
The problem is NOT tight schedules. The problem is that developers everywhere seem to think they have no control over the schedule. However, some developers have it figured out: Break the schedule into three categories and allow the person who wants the job done to define two of them.
The categories are time, money, and people. Every project is measurable in the amount of time it will take, how much money will be spent (not head count), and how many people will be involved. The smart approach is to let the manager define two categories and you define the third. If a manager says they want a 6 month project done in one week and only spend $200, you get to say you want a team of 1,000,000 employees to do the project. Those are not unreasonable figures. The manager is asking for the impossible and you are making it possible by getting the resources needed to accomplish the task in the required amount of time on the specified budget. A six month project done in three months and spending $10,000 might require a headcount of 20 people to get it done on time. A six month project done in six months and $7,500 might require a headcount of 8 people. Any manager worth his/her salt can see the latter two are much more realistic. Obviously, I am just chucking numbers out there, but the reason developers don't sleep at the end of projects or go home late is because one of the three categories is not balanced properly.
Of course, some developers literally have no choice in the matter because their managers think they know everything and are control freaks. They have high turnover rates and the people higher up see something going on, but would never dream that the manager is the real problem. Very few developers make good managers, but the few that do are really good. They know how development works and act as liason to the "higher-ups" to get extra time or money or people for the team to create that balanced schedule.
The problem is NOT tight schedules. The problem is that developers everywhere seem to think they have no control over the schedule. However, some developers have it figured out: Break the schedule into three categories and allow the person who wants the job done to define two of them.
The categories are time, money, and people. Every project is measurable in the amount of time it will take, how much money will be spent (not head count), and how many people will be involved. The smart approach is to let the manager define two categories and you define the third. If a manager says they want a 6 month project done in one week and only spend $200, you get to say you want a team of 1,000,000 employees to do the project. Those are not unreasonable figures. The manager is asking for the impossible and you are making it possible by getting the resources needed to accomplish the task in the required amount of time on the specified budget. A six month project done in three months and spending $10,000 might require a headcount of 20 people to get it done on time. A six month project done in six months and $7,500 might require a headcount of 8 people. Any manager worth his/her salt can see the latter two are much more realistic. Obviously, I am just chucking numbers out there, but the reason developers don't sleep at the end of projects or go home late is because one of the three categories is not balanced properly.
Of course, some developers literally have no choice in the matter because their managers think they know everything and are control freaks. They have high turnover rates and the people higher up see something going on, but would never dream that the manager is the real problem. Very few developers make good managers, but the few that do are really good. They know how development works and act as liason to the "higher-ups" to get extra time or money or people for the team to create that balanced schedule.
Comments
Post a Comment