That kills developer productivity

In light of the fact that Megamind was reunited with Habr again, now we can expect that the audience of both portals also merged. It will be logical to assume that Habr will attract more attention of managers who are not alien to the world of modern technology. Therefore, our SmartProgress team decided to prepare an article at the crossroads of project development and management.

We hope that this post will help managers to better understand programmers and not to tread on those rakes that most managers and managers take with might and main - everyone wants the code to work like clockwork, but the authorities forget that developers need to develop excellent code.

"Productivity measurements"

You can not control that can not be measured - this is one of the favorite axioms of the guild of managers. But no matter how you say it, no one has yet been able to adequately evaluate the productivity of developers. The brightest minds of IBM, Microsoft, Intel, and many other titans of the IT world struggled on this issue, and so far the metric that could be used to measure the productivity of programmers has not been found. If this seems absurd to you, then offer your thoughts - what if you find yourself right? Then you will become a real star in the IT universe, and you will write books about you and your genius.
')
So the problem is that there are no metrics with which to measure developer productivity. What is the way managers find? They diligently try to measure at least something - they keep records of the daily written number of lines of code or freshly developed bugs, the number of projects submitted on time and other not less important things. The worst scenario in this case is the attempt to motivate developers and introduce penalties for “failure to fulfill the five-year plan” or delay in the delivery of the project. After all, programmers are not bored. Want more code? It can be done. Bugs - we will fix in two shifts, especially if they give a bonus for it. Only the productivity under the prism of the quality of the code itself, such an approach affects very negatively.



How to help this trouble? Dozens of treatises have been written on this score, and no consensus has been found. One thing is clear: organizing the workflow and coordinating the creation of software, you do not need to put pressure on programmers with your own metrics. But let the managers not panic - they still have a lot of things to measure and record. For example, it is possible (and necessary) to track which particular obstacles slow down the work on a project, how long these or other tasks take - later it will help to more accurately estimate the timeframes for such projects.

Thinking in the spirit of "I will fix it later"

The project plan is always not enough days, and in days - hours to create everything that was planned. Therefore (and for many other reasons), the developers turn a blind eye to the bugs and the "crutch" solutions that work here and now are used just for the delivery of the project. This is how technical debt appears and accumulates, which one day will have to be repaid. The more debt, the more it grows in the subsequent stages of development and slows down the project. It turns out a vicious circle - they wanted to quickly, but it turned out as always, that is, exactly the opposite.



Each project has a technical debt - sometimes it can be managed relatively quickly, but it often grows to gigantic sizes. The more debt, the more time you need to pay it off, and time, as you know, is money. Therefore, it happens that it is easier to write a new code, rather than fight with the old one.

How to deal with thinking in the spirit of "I will fix it all later"? First of all, managers and customers should listen to what programmers are trying to convey to them. Very often, the implementation of the best solutions takes more time and postpones the release of the product, which neither managers nor customers do not like. However, this subsequently justifies itself. Of course, the cases are different, but one thing is for sure - no developer would like to deliberately put a stick in the wheel, because then you will have to cope with the consequences yourself.

Too little documentation.

Documentation takes time, and developers are paid for writing code, evaluate their work by the number of written lines and debugged bugs (if they are not able to evaluate otherwise). Managers want results - the developers and work on the result. “But what about the documentation?”, You ask. “And we all remember, and we will definitely write everything when there is time for it. Chesslovo! ”Programmers will calmly answer you.

Too much documentation.

And although everyone is accustomed to projects without documentation, projects that are mired in a bureaucratic quagmire are very common, too many words and little code. This is dangerous when the company pays the documentation "by weight". Then, instead of comments, in fact, you can expect long and heartfelt speeches about every little detail of the code, which will take several months to read. What they wanted was what they got.

Love of antiques

Why rewrite ancient code when it still works? Why use new technology when there are old proven solutions? On the one hand, these are correct remarks, but you should not forget that saving the old code is time and money. It is necessary to translate everything from one programming language to another, it is not easy and hides a lot of pitfalls. Undoubtedly, programmers can do a tremendous job, changing and straightening ancient systems and polishing old logic instead of creating new ones productively and moving forward.

Circus in the workplace

It's great when business owners remember cool things like billiards or ping pong in the office. But very often, everybody forgets about the fact that for productive work it is important for developers to focus on their code, and this requires silence. Conversations, key knocking, ringtones and other other "charms" of openspace pull developers from the abstract world of algorithms. And then they need time to re-switch to work. These are seconds, minutes - but on the scale of a whole project, such things can negatively affect not only the speed of writing code, but also its quality, and most importantly - shatter the delicate emotional balance of the programmers themselves.

Notorious meetings

Managers like to talk, and these conversations are in most cases incomprehensible to programmers. Famous story - managers are ready to spend hours discussing “organizational details”, preventing developers from focusing on core tasks. Or another scenario - the programmers themselves at meetings can spend hours crying about all known bugs instead of debugging them. Therefore, often meetings aimed at increasing the productivity of developers, not only do not give the desired result, but also act exactly the opposite. In addition, such gatherings in the middle of the working day distract the creators of the program code from the abstract world of algorithms, and in order to re-tune to the working mode, they need time.

How to deal with it? Since there are still quite a few positive aspects in meetings, in this case it is necessary to monitor only in order not to overdo it with their number and duration. Less is better. We discuss only the most important and as concisely as possible.

If you decide to follow the tracks of some progressive companies and completely abandon meetings, then you will need good communication mechanisms. Here, too, the measure is important - do not overdo it with letters and reports, because for developers it is even worse than meetings. And in order to work effectively with planning, set goals and jointly go to them, your company can be helped by our service, which also helps in tracking progress and increasing motivation.



So we hope you enjoyed the post. Maybe you have something to say about the factors that kill the productivity of developers? We will also be happy to see in the comments life hacking to improve this very performance.

SmartProgress - achieving goals