People in the project
In every project, there’s someone who tests, supervises, checks the progress against the goals and business objectives. There’s someone responsible for the contact with the customer, requirements, quality assurance. Rarely it’s something a software engineer must worry about. These people make plans, meets with customer representatives, test application, and so on. Their job is split into time-framed tasks.
In the same project, there are software developers. Developers solve problems that require a deep understanding of the whole system and a situation. They need to remember many things at once. Consider the context of the operation they currently work on. Everything from names of variables, data structures, important APIs, the names of utility functions that they wrote and call a lot, even the name of the subdirectory where they store their source code. They work in task-framed chunks of time.
Impact of interruption
Whether the manager, tester or the developer: none, of course, likes to be disturbed in the middle of a thinking process. And the last thing a dev wants to do is to jump into a business meeting out of the blue.
However, something that is a small interruption to an average person can be a disaster for a developer.
The developer, when working with code, will methodically go through the code to understand, refactor and change the functionality or fix the bug. And when he/she is adding new features it’s even more absorbing (depending on the complexity of the feature).
Now imagine what happens when you approach the developer in a middle of that task? Now, if you think he/she can pick up where he/she stopped you couldn’t possibly be more wrong.
We can’t! Not without a hit on every level – time, quality, and the ability to think deeply.
When I concentrate on writing a code it doesn’t take much to put off stride.And the worst are those days when there’s a lot of demands on my time so that I forget what I was doing in the first place. The days when one minute the architect is asking me about the application’s impact on the client’s system and the next a person from customer’s contact is telling me that I must explain to him how the new report is working in case the customer will have questions. Not to forget about overflowing e-mail and instant messages. After few hours of such distractions, the simple code written in the morning might as well be in Japanese.
And I know there’s more developers like that.
Developer’s need of “undisturbed” time
Planning and building a complex IT systems is a difficult and unpredictable process, and there will be challenges that come up along the way. People, who don’t write a code, do more time-framed tasks or have more procedural jobs underestimate context switching cost that developers are facing.
Please remember: every developer needs quiet time during a day to get his/her job done. Even though developers are fully aware they can’t completely avoid interruptions, there are times when one single moment can cost hours of work. It will influence developers’ productivity and thus a project outcome (it’s nice shown on this picture).
A team’s culture constantly evolves through a number of small actions and decisions that gradually turn into regular patterns and ways of working. When you understand what the developer’s day-to-day life is like and where they are coming from it’ll be much easier to understand each other and to work through challenges that are yet to come.