Developer productivity is not an easy topic. In many managers points of view the product is often not developed fast enough, presented estimates too big and developers are focusing too much on robustness of solutions for which customers just would not pay. On the other side, developers frequently perceive managers as people pushing forward without looking at the current situation, ignoring some technical consequences of their decisions and forcing programmers to create rubbish and cheap solutions. The fact is that there is always not enough time to create a product in the technical way with which we would like to. Many developers are hopping from job to job in a search of a holy grail project. To meet both sides expectations, some standard can be set and developer productivity measured.
Unfortunately, here even bigger obstacles emerge. How the heck do you measure developer productivity? I will not even mention lines of code metrics as it simply tells you almost nothing. The number of bugs or issues solved is also not the best one. It is very hard to assure that each task is equal in terms of required amount of time to finish. Most of the currently used metrics are only half measures. Very often the biggest impact have a more or less biased leader or senior developers opinion about a specific programmer.
While it is very hard to measure productivity, we can more easily identify what things have a negative impact on it and try to remove them. By the way, it would be great to have good measuring methods to check how removing each of the problems listed below would affect performance:
- lack of fast and good unit tests – under such circumstances introducing any change is rather troublesome. The developer does not know what exact behaviour the code should provide and if their change has broken anything. Diligent developers might spend enormous amount of time verifying correctness of their commits. Not being diligent enough might introduce major bugs. Professional ones would spend quite a lot of time allocated to issue for unit tests creation (which is IMHO the right way),
- project compilation and local deployment takes quite a lot of time – while what amount of time is too long might be disputable, several minutes is quite a lot for sure. Imagine that after each change a developer has to wait 10 minutes to check application behaviour. It is quite distracting and demotivating and can significantly lower the performance. To countermeasure it you can not only spend some time on tuning the build but also use one of the frameworks for reloading code changes instantly (like for example JRebel),
- developers Continuous Integration feedback loop takes a lot of time – after the commit is pushed to repository, your CI server should present results as fast as possible. If a developer needs to wait for more than 1 hour for their commit results they can simply forget about it or check it another day. Under such circumstances it is difficult to create a feeling of common responsibility for the project. It might happen that one dedicated person would need to be a CI watch and will have to monitor builds, spend time on failure analysis, notify responsible programmers and ensure that they have fixed what was broken,
- badly structured code (code name: spaghetti code) – the bigger the amount of spaghetti the more amount of time is required to introduce a change. It is harder to track dependencies. A lot of code needs to be checked and deeply investigated to fully understand what is going on and avoid regression. Each change might have an impact on many modules that look like they are not related. The chances to introduce bugs are big,
- requirements are not clear – quite a common case in software development. In such a situation developers often spend more time on research what in fact needs to be implemented than on the implementation itself. Additionally, as a result it frequently happens that implementation is not exactly what the customer wanted and additional work is required to handle the requirement. What’s worth mentioning is that depending on staff characteristics, it might be a really demotivating factor,
- lack of motivation – the last but not least. It is one of the biggest performance and productivity problems. While of course some people are more or less motivated by their nature, an employee has the biggest impact on this factor. It is strictly the responsibility of leaders, managers and organizational culture if developers will be motivated or not. Usually it is mainly about the atmosphere and relationships.
Most of the above issues are not easy to address. Some require aside projects that do not bring immediate value (no customer paying for them), some need major organizational changes. What I find the most difficult here is to create business cases for them. How to exactly measure developer productivity and how to estimate how each change would affect it. The lack of clear indicators is usually a blocker for many organizations to start changes or projects solving the above problems. Very strong conviction and developer feelings are often not enough.