Blog

From a programmer’s viewpoint


Let’s begin with terminology. By right the principal term is considered an “ideal hour of a programmer”. That means the ideal hour is the time spent by the performer only on the task.


 

There’re two differing approaches to the process of setting and estimating tasks:


 

1. The first one is based on the concept of the “ideal hour” and it goes “from above” - the manager, being guided by the suggested ideal estimations, sets terms for the task and delegates it to the programmer.


 

2. The second approach is also based on the concept of the “ideal hour”, but it corresponds not to the manager, but to the programmer who will do the task. The estimation is given according to the skills and opportunities.


 

In the first case the estimation is based on an average estimation. It is acceptable for both big and small companies with similar qualified employees. In the second case we have a more actual estimation, but from the programmer’s point of view. However even this isn't enough. The programmer may be experienced in code writing, but having no experience in task estimating, he won't be able to estimate an extensive or highly specialized task correctly.


 

To delve deeper, we will consider quite a typical situation in a small regional web studio. Programmers give estimation, then managers average it and set the task. Okay, from an outside viewpoint it looks adequate. But there’re some “buts”:


 

1. The inexperienced programmer gives an underestimation


 

2. The inexperienced programmer gives an overestimation


 

3. The unfair programmer gives an overestimation


 

4. The fair programmer gives an overestimation


 

5. The programmer gives an idealized estimation


 

Let’s consider each case in more detail. In the first case we get a project delay. The second case leads to additional questions from the customer in financial aspect. The third one is perhaps the most harmful both for the programmer and the web studio. Just because the remaining employees may be guided by the overestimates of this programmer. The fourth case – the programmers constantly study and gain experience. Someone does it quicker, someone does it slower. And one day there comes a programmer who previously could set tasks to himself, or his manager was of that kind that it was necessary to set tasks himself. That’s why there comes the overestimation. The fifth case – it happens, but it belongs to the underestimation, because there’s neither ideal working day nor ideal conditions for the project.


 

By the way, we can add one more term here – a “wasting time ratio”. Roughly speaking, this is the ratio of unproductive hours to the productive. Perhaps, the best characteristic of the programmer’s working day.




 

For example


Doing a task – 3 hours 

 
Meeting – 30 minutes 


Smoke break – 15 minutes 

 
Coffee break – 15 minutes 

 
Doing the task – 1 hour 

 
Micro meeting – 15 minutes 

 
Getting back to work – 15 minutes 

 
Doing the task – 1,5 hours 


Smoke break – 15 minutes 


Coffee break – 15 minutes


Micro meeting – 15 minutes 


A phone call – 15 minutes


 

It’s obvious from the list, that the programmer’s time of working at the task is 5,5 of 8 hours => wasting time ratio = 3,5/5,5. This estimation characterizes only this task. To get the whole working time it’s necessary to sum all the estimations. By the way, best companies are of the approximate ratio 1/7.


 

From a manager’s viewpoint


 

Now take a look at this from the other side. From a manager's viewpoint. Project managers aim to sell programmers’ work more expensive and customers want to buy it cheaper. The bargaining comes to an end and all of them come to some estimation. Now the manager has the right to demand from the programmer of project implementation in due time on the basis of ideal hour. But, as I have already said, there’re no ideal projects and the “advanced” managers make corrections to the ideal hour. It also comes with going through the school of hard knocks. However there are cornerstones.


 

If we have an ideal spherical team in a vacuum, this estimation suits us and it will be the only true one. But as we know, there’re no such teams. There are different types of people of different skills and different qualification in a team of programmers (to take a separate department). It is necessary to consider it when setting and estimating the task.


 

To take such case: a programmer was working for 10-11-12 hours the day before just because of the work involving all hands. Next day his working capacity cuts approximately by half. If the programmer hasn’t had a good sleep, he would be inattentive and sluggish. And it also affects the accomplishment of terms, especially during transition from one project to another.


 

All these nuances influence terms of the accomplishment of tasks, and, as a rule, not to the best.


 

From a teamlead’s viewpoint


 

The only thing left is to look at the task setting and estimating from a teamlead’s point of view. This person is a link between managers and programmers. In most cases their “wasting time ratio” is higher than the staff’s one. However “the power over time” is concentrated in their hands. Setting and estimating of tasks in the process seems more adequate, than the two previous ones.


 

It’s a compromise between setting of ideal and personal time.


 

In my opinion, it would be correct to adopt Google’s experience in strict task setting to programmers and to adapt it under requirements of any separate small, medium-sized or big company. 


 

1.    Setting of a task from above.


 

2.    The task is concrete, detailed, structured into elements and subtasks.


 

3.    The task is set to a particular person at once.


 

4.   The task is estimated by a teamlead or an experienced programmer with an eye to the responsible person.


 

5.    The programmer must complete the task on time.


 

6.    Minimizing the waste of time.


 

7.    One person is involved in technical support, if it turns out to be difficult – another one is being involved. 


 

8.    It’s desirable to change a technical support manager once a month.


 

9.   Bugs are fixed by the person who did it. If there’s no such person, then fixing goes to a man doing similar task. If there’s no that one either – it goes to the most experienced one or the teamlead.


 

Author: Georgy Ionov, a programmer of web development department


Back to the list


0
Guest
Name Quote 0
Message Text*
Spam bot protection (CAPTCHA)
 
777en