Whether in programming, or software development, or testing – in most cases the assessment of project labor costs is an intuitive process. Project managers, who communicate with the client, rely on intuition as well as developers, who give «hourly oaths» to managers. Whether it’s worth trusting intuition and what dangers it bears in herself – we will discuss it in the article below.
Another planning meeting in the web studio, programmers being brought up, and you’re already sitting with a notepad containing the task list. Guys pretend being unfortunate with someone’s temperature sudden rising, but right now begins the most interesting thing – you’re going to start to distribute hours and to demand to plan labor costs from programmers.
Further – as luck would have it. A programmer John Doe with 3-year experience will estimate the most complex challenge up to a minute, while Fred Roe having the same experience level will utter: «Well, I don't know exactly…» Rupture of a template? No, psychology involved.
Yes. Just do what you want to learn. Constantly and abundantly. When we set time frames for ourselves, we are based on our own experience, not on the other person’s one. Such peculiar internal measurement. Do you remember the way we were taught in the childhood – morning exercises and once again morning exercises? It’s like that.
In programming the assessment of labor costs is equated to intuition. To a greater or lesser extent, but the fact remains – one can’t do without «intuition». Let’s assume that you ask John Doe to estimate a software development task, and then he will say: «So many weeks, so many hours». And now we will try to give the task to Fred Roe – to estimate the development of an oil field near his house. The way things will turn out is clear without wasting words.
To sum up: the experience in a certain area plus continuous practice will help to solve the problem automatically and to decide on time. It’s like a tasty beefsteak – it’s enough for you to see it, your stomach will do the rest.
But don't forget that even when you get «pumped up» - you will measure tasks by ideal spherical time. As if you were in vacuum. For example, do you always consider in case of the assessment of labor costs of any program project such principles as «where the fifth cup of coffee is, there the tenth one comes», «walk and warm up» etc.?
The assessment «from above» is an ideal method of psychological pressure. It was used by Stalin at meetings with commanders, it is also used by programmers, more specifically, their chiefs. "Die but do".
After all for the responsible and ambitious programmer the failure on terms is a blow to the ego and his professionalism. When a chief asks to estimate a task – the developer tries to grope an internal compromise. On the one scale – mobilization and the underestimated terms, on the other one – ideal terms for the programmer and pretty scolding from the chief. One has to choose the better of two evils.
1. The following rule works in 90% of cases – increase the calculations of a developer by two and get real terms. The reason is the idealization of a daily routine and «robotizing» the person.
2. Don’t forget about the time idealization. Programmers and their assessment of labor costs on creation of any site or software belong to different temporal dimensions. The developer neither eats, nor drinks and, of course, has no rest.
3. Productivity idealization. As a rule, programmers-beginners get to this trap. They feel perfectly well on Mondays, they have high working capacity, and they have no idea about such words as «I didn’t have a good sleep» and «Monday is surely worse than Sunday».
4. The complexity of planning of labor costs to spend for research and searching for the decision. It’s an urgent problem if the task is not too standard or the employee is just not skilled.
5. High code cohesion. In case of changing a simple code location developers can shovel all the structure. Whether the time is put in the assessment is a rhetorical question.
6. Mistakes. Nobody would ever admit the intention to make mistakes, to break a code, etc. It’s another kind of illusion. We are all humans.
7. Editing of connected or found mistakes. It’s the delusion from the category of rhetorical questions like «Did I plan to correct the code of my predecessor?».
8. Non-standard tasks. If a programmer tries to estimate them without preliminary research, it will be the assessment «out of the blue». Add to it psychological aspects, self-confidence and the current congestion. Non-standard tasks need the preliminary task «to make an assessment». Here you can research the problem, try the forces, not to saturate yourself in the subject but to be convinced of operability of the found solution.
9. Compound tasks. They are comparable only to a marathon. Real terms of compound tasks are always greater than planned. Therefore the main help of the programmer to work with them is splitting them into subtasks and the assessment taking «time leakage» into account.
10. Inspiration. Yes, it happens even to programmers, not only to designers or artists. Therefore during the planning and the assessment of labor costs consider any possible factors, destroying the «unification» of a code and the developer.
11. The underestimated assessment under pressure. That kind of assessment influences fatally both the work of the programmer, and the quality of the code. Then comes the chain reaction: low real labor productivity, demoralized mood, processing of the created or the development of the new.
12. «Corrections». A typical situation in a web-studio – 3 lines of the code corrected and 2 or 3 hours spent. Why spending so much time instead of 15-30 minutes? Simple as easy – the time is spent on studying of a problem, lining of logic and structuring it in the mind.
Author: Maxim Kuznetsov, the programmer of department of the high-loaded systems