In most jobs, the expectations for software developers are that they must work in a fast-paced environment, should be able to juggle multiple tasks at once, and maintain the same level of productivity. For example, working on multiple unrelated projects and dealing with their stakeholders all at the same time is foreseen.
We all have worked in jobs where there are new things popping up that needed our attention. Nonetheless, people are not machines and each time a person has to change tasks or projects, performance is affected. These changes in tasks also come with changes in context that the person needs to adapt to before continue being productive.
Context Switching
When a person is taking on multiple projects, for each extra project, there is a loss of up to 20% of the time by just switching between projects (McGreal & Jocham, 2018). Thus, if you have three projects, there is around 40% of time loss by just context switching (McGreal & Jocham, 2018). I experienced this when I was a full-time developer. Some areas of the business might not understand that developers need to concentrate so they can code properly because they are solving an intangible problem. It is easier for a painter to stop painting for a while and do something else. The wall is something tangible and he can come back without thinking twice to continue exactly where he left offs without a loss in productivity.
Researching
That really does not happen with software development. A developer needs to concentrate on the task at hand and the context of the work or problem that she is solving. If a developer stays away from a project because he is working on another one, it will take a long time to come back and understand or remember what he was doing. Even if he created all the code of the project and read the comments he made along the way, it takes time to get back on track. Sometimes, developers are reading about the issue online, search in the documentation, or studying other code so they can be more effective at their work. Therefore, if a developer is not coding, it is not because he is not working, he is looking for the best solution possible for the job or at least to get the job done.
Productivity
In a study done by the University of California Irvine, a person is interrupted while working an average of once every eleven minutes (Crenshaw, 2010). So, it is difficult to concentrate on coding if the developer is interrupted that many times during the day. I think that developers should be left alone but with your door open for questions that they might have about the product. If there are impediments that don’t allow developers to progress, they will let you know and you should be the one to solve those issues. Developers are not monkeys coding and creating software. In order to be productive, they need to concentrate, research, communicate between themselves, code, test, and iterate over the steps until they can arrive at a done feature.
When measuring productivity, context switching and the number of projects that developers are working on should be considered. No lines of code or just features shipped. The faster that developers are pushed to work and the more context switching they have to perform, you will be creating technical debt considering that they have to look for shortcuts to ship the planned features on time. Also, that does not consider burned-out developers that would later quit because of the pressure to deliver the product on time.
References
- Crenshaw, D. (2010). The Myth of Multitasking: How “Doing it All” Gets Nothing Done. John Wiley & Sons.
- McGreal, D., & Jocham, R. (2018). The Professional Product Owner. Addison-Wesley Professional.
