A study on unplanned interruptions in software development

This article is part of my academic project on “Software Engineering Process” course, which was submitted to Dr. M. Rokonuzzaman. We were a group of three members – S.M. Shamim, Md. Aminul Islam and me (Md. Arshad Hossain). Instead of posting total long document, I would like to add some of focused section of it.

-:-

This is the full contents list of our original project article. But here I included only highlighted (black) sections. If you want to see complete project document, you can contact me (Md. Arshad Hossain [connect2arshad AT gmail DOT com] ).

Table of contents

1. Introduction
2. What is Interruption?
3. Types of interruptions
4. Interruption Channels
5. Characteristics of interruptions
6. Observation on daily interruption of a software professional:
7. Nature of interruptions
8. Some studied scenarios
9. Survey
   1. Survey on Company 1
   2. Survey on Company 2
   3. Survey on Company 3
   4. Survey summary
10. Effort Loss and Effort Saved Analysis
11. Implication
    1. Positive implications
    2. Negative implications
12. Root causes of interruptions
13. Survey Respondent Recommendations
14. Minimizing Interruption
15. A Guideline to improve interruptions using Performance-centric process (10-Elements)
16. Conclusion

Introduction:

Developing software involves creative work and requires absolute focus and concentration. It is well known that developers work best by getting into a flow, a mental state where they are fully concentrated on their work and fully in tune with their work environment. This is the time when developers produce great work and are most productive.

Getting into a flow of work with absolute concentration is not easy. It is said that it takes on average 15 minutes, to take all relevant information like the problem which needs to be solved, possible solutions, associated methods, variables, parameters and object structures, into a short term mental space and are ready to work. And if a developer has already done creative work getting into a flow like that for once or twice, it is unlikely that she will be able to get into that mental space with absolute focus for the rest of the day.

The problem for the developer is that it is very easy to get knocked out of that work flow and the details in the short term memory can get wiped out, if they are interrupted. Productivity depends on for a creative worker being able to continue work without being interrupted.

What is Interruption?

Interruption, in the context of software development, is an event which causes a creative worker to lose focus and concentration while working. This event can rise for all sorts of reasons in different forms and shapes. The most interruptions happen because of a co-worker. If a co-worker asks a question which causes a 1 minute interruption, it has far greater impact and consequences than the one minute interaction. Because, even though it’s a one minute interruption, it can knock the person being interrupted out of the work flow and focus, and it might need another half an hour for that person to get fully productive again.

In addition to the interruption which occurs out of the need for communication, there are other forms of interruption which could be equally destructive. Noise, phone calls, email notification, need for tea or coffee, going out for lunch, are the few other examples of interruption.

Observation on daily interruption of a software professional:

Productivity: In general we say, productivity = output/input; but, to me, in software development or any intellectual profession this equation cannot outline the real productivity. For example, an analyst may take several days to design a software architecture (like- relational model) which visible output may be one or two pages. Again, to solve a critical issue a developer may take several hours but it’s visible output may be five to ten line of codes.
The real productivity of an intellectual professional mainly depends on total uninterrupted time given to the production which includes doing nothing but thinking.

Here is a graph of a software developer daily production line dealing with interruption-

Nature of interruptions:

Interruption can occurs by one or more persons, by an application, by tools or machine or any kind of external instinct. But, normally when one person asks another person for any reason during the working time is assumed as interruption.

Best case: The interruption in which interrupted person hardly need to give any feedback, which takes smallest time. Like-
-“Hey, I am going to take a cup of tea”.
-“Please give me your pen”
-Somebody entered the room.

Regular case: The interruption that needs interrupted person’s physical appearance stopping his/her own task.  

Worst case: Interruption that needs interruption person’s physical appearance as well as subsequent person’s (one or more) involvement to help solve the problems by stopping their own task, which may cause disaster in productivity.
When an interruption occurs, in regular case basically it takes following time segments-

Where,

A = The person who needs help
B = The person who is asked to help

t1 = The time when a need help
t2 = B is free to listen to A’s problem
t3 = A described the problem to B
t4 = B found the solution
t5 = A understand the solution

T1 = t1-t2 = A waited for B get free
T2 = t2-t3 = A described the situation/problem to B
T3 = t3-t4 = B did analysis the problem and found the solution
T4 = t4-t5 = B described the solution to A

In this process, B was always busy, but A had to wait and for several segment of time.

Let say, Tz is the actual time need to do the work (problem) by A if interruption was not needed.

But, A total time taken = T1 + T2 + T3 + T4
B total time taken = T1 + T2 + T3 + T4
So, Total time taken by both A and B = 2*(T1 + T2 + T3 + T4)

But, at the end of the interruption both A and B have to take some time to go back and start their own task productively, which here we called Ts,
So, Total time taken by both A and B = 2*(T1 + T2 + T3 + T4 + Ts)
Ts = switching time

Now, total interruption cost in regular cases is =

Tc = 2*(T1 + T2 + T3 + T4 + Ts) – Tz

Tc = total interruption cost
Tz = actual time required, without need of interruption.

But in worse cases, where more than two people are involved within a single interruption, the cost would just be multiplied.

Tc = n*(T1 + T2 + T3 + T4 + Ts) – Tz

n = number of people involve

Implication:

Positive implications: The key to a successful project is good communication. We should  put obstacles in front of communication within your project, people will slowly just stop asking about those little “meaningless” things. It turns out, those meaningless things are often not that meaningless after all, but those nuances that takes our product from merely good to excellent.

If a developer works in a team or in such an environment where several projects are developing and all are willing to share their experiences and difficulties, literally every developers can gather and aware of more than one project experiences at the same time. So, organised and efficient interruptions can help a professionals in many ways-

• Knowledge sharing
• Identifying project risk
• Improve product quality
• Code/design refactoring
• Improve project prediction

Negative implications: “Interruption is the enemy of productivity” – Jason Fried of 37Signals wrote in his “The Way I Work” article on Inc.com magazine.

Some interruptions do not stop within 2 persons, it may spread though out the team, which may occurs a huge production loss. Specially those interruptions which are not related to technical or managerial, have a very few positive implication.

So, there should be well defined and structured communication channels. These are some negative implications that place within the companies-

• Project delay
• Productivity falls.
• Cost of delivery increases.
• Concentration loses.
• Quality may suffer.
• De-motivation may occur.

Root causes of interruptions:

• Lack of skill and knowledge
• Ambiguous and unclear specification
• Miss communication with stakeholder.
• Poor design
• Dependency.
• Lack of confidence.
• Lack of proper process
• Poor management skill
• Resource unavailability
• Poor resource utilization.
• Poor work environment.
• Lack of seriousness and dedication.
• No written communication.
• Not following any standard/efficient process to develop.

Minimizing Interruption

The purpose is to reduce the no of interruption and their severity. We are suggesting the following measures which we hope will improve the +ve contributions and reduce the -ve contributions of interruption if introduced in the company work process. There are two different scope of work, one for the management to follow and the other for the individual employees to follow.

For the Management

Educate employees

All employees should be made aware of the negative impact of unnecessary interruptions. A lot of random interruption can be avoided just by being conscious that they way people talk, behave and walk might cause interruption to others.

Communication medium

Rather than using phone or verbal communication, it is much more efficient and interruption free for others if email is used as a means of most communications. Because email does not cause spontaneous interruption and can be replied on convenient time.

Employee sitting arrangement

No more than five people should be seated in a single room and also if possible people working on different projects should not be seated in the same room. If large open space is used for developers, it has to be make sure that sufficient space is there between different teams. This is very important because on of the most frequent and severe interruption is side talk

Task assignment

The project manager or Team lead has to assign and track tasks to each developer under him. A person without any work for certain period of time is most likely to interrupt others.

Multiple project

A person’s productivity goes way bellow normal, if he or she is assign on multiple projects. Work context switching is a time consuming and costly task to do. If possible, the manage should make sure that a person is assigned with a single task at a time.

For Individuals

Consolidate Interruption

A person should try to anticipate interruptions and try to deal with them at once. For example, there is a scheduled meeting, try to disseminate as much information as possible and try planned task distribution so that very little time is spent for the same purpose later. Also, do the things like checking personal mails, social networking sites, having coffee just before or after the meeting.

Anticipate

If there is a planned interruption like meeting coming up, try to take some notes about the work being done and the next intended work. This will become very useful reminding the situation you were in before leaving the work.

Development style

Try follow agile way of writing code, like simple design, code and test. This way you would not need to bring a complex scenario in mental space and then lose it because of an interruption. Try to have fast computing power and smart build tools. The time taken to build the code, is a common source of distraction and take the developers to other things.

Better use of interruption time

Once you have been interrupted severely to the point that you have lost all your short term memory space and got very annoyed and frustrated, stop trying to work on it right away. The better use of the time right after the interruption, would be to read some books or articles.

Conclusion:

Interruption is part of work. Nobody can expect to lock himself away and work alone interruption free. So there needs to be a collective effort and awareness to curb the common unplanned interruption. On average about 40% of working time is lost because of interruption, not all of it should be counted as waste, some of it is unavoidable and some it can actually increase other people’s productivity. For a company’s continuous growth it has to maximize productivity and one of the way to do it is to have a defined process to follow when a need arises to communication with one another.