DZone
Thanks for visiting DZone today,
Edit Profile
  • Manage Email Subscriptions
  • How to Post to DZone
  • Article Submission Guidelines
Sign Out View Profile
  • Post an Article
  • Manage My Drafts
Over 2 million developers have joined DZone.
Log In / Join
Refcards Trend Reports Events Over 2 million developers have joined DZone. Join Today! Thanks for visiting DZone today,
Edit Profile Manage Email Subscriptions Moderation Admin Console How to Post to DZone Article Submission Guidelines
View Profile
Sign Out
Refcards
Trend Reports
Events
Zones
Culture and Methodologies Agile Career Development Methodologies Team Management
Data Engineering AI/ML Big Data Data Databases IoT
Software Design and Architecture Cloud Architecture Containers Integration Microservices Performance Security
Coding Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks
Partner Zones AWS Cloud
by AWS Developer Relations
Culture and Methodologies
Agile Career Development Methodologies Team Management
Data Engineering
AI/ML Big Data Data Databases IoT
Software Design and Architecture
Cloud Architecture Containers Integration Microservices Performance Security
Coding
Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance
Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks
Partner Zones
AWS Cloud
by AWS Developer Relations
The Latest "Software Integration: The Intersection of APIs, Microservices, and Cloud-Based Systems" Trend Report
Get the report

Waste #6: Task Switching

Matt Stine user avatar by
Matt Stine
·
Sep. 16, 10 · Interview
Like (0)
Save
Tweet
Share
37.25K Views

Join the DZone community and get the full member experience.

Join For Free
Welcome to episode six of our series "The Seven Wastes of Software Development." In episode one, we introduced the concept of eliminating waste from our software development efforts. Waste elimination can be traced all the way back to the the mid-1900's, the birth of lean manufacturing, and the Toyota Production System (TPS). This is how Taiichi Ohno, the father of the TPS, described its essence:

All we are doing is looking at the time line, from the moment the customer gives us an order to the point when we collect the cash. And we are reducing the time line by reducing the non-value adding wastes. [1]


In this episode, I'd like to focus on "Task Switching." Of all of the wastes confronting us as software developers, this one is perhaps the deadliest. Deep concentrated thinking is required for even minimum effectiveness as a software developer. Interruptions are the ultimate enemy of deep concentrated thinking, and any task switch constitutes an interruption.

Read the other parts in this series:

  • The Seven Wastes of Software Development - Introduction
  • Waste #1 - Partially Done Work
  • Waste #2 - Extra Features
  • Waste #3 - Relearning
  • Waste #4 - Handoffs
  • Waste #5 - Delays
  • Waste #6 - Task Switching
  • Waste #7 - Defects

The cost of task switching in software development has been a recognized problem for many years. Tom DeMarco and Timothy Lister highlighted it in 1987 in their influential book Peopleware: Productive Projects and Teams.

DeMarco and Lister were two of the first to describe flow - the holy grail of coding. Flow is that state of uberproductivity in which time disappears. The computer becomes an extension of your mind as the code flows down through your nerves and out through your merrily dancing fingertips. Flow is when value is manufactured.

Unfortunately, getting into flow is extremely difficult. It takes us at least fifteen minutes to get there; it is the time we spend loading the problem at hand into our minds. And during that fifteen minutes, we don't get anything done! Once we're there, any interruption forces us to begin anew, costing another fifteen minutes of unproductive time. Four interruptions costs an hour of productivity. Thirty-two interruptions costs a day.

The true cost of task switching is best illustrated rather than described. In the first diagram below I've depicted three tasks, each of which is estimated at one week to complete.

 

Task Switching Diagram #1
Let's imagine that each of these tasks will deliver value to a different customer: task one to customer A, task two to customer B, and task three to customer C. In this serial completion scenario, whereby the developer focus on one and only one task until it is finished, customer A realizes value after one week. Customer B realizes value after two weeks, and customer C realizes value after three weeks.

Now let's examine the all too common task switching scenario. Our developer's manager wants to see positive progress made on all three tasks immediately. We'll assume only the best intentions on the part of our manager. It's quite likely that he simply wants to assure his customers that their items are in progress and will be completed as soon as possible (or so he believes).

So, our developer takes each task and divides it into eight equal parts. He then completes part one of all three tasks, followed by part two of all three tasks, followed by part three, etc. I've added this workflow to our earlier diagram below.

Task Switching Diagram #2

While the picture is indeed worth a thousand words, I can't help but highlight the value delivery story:

  • Week One - NO VALUE DELIVERED
  • Week Two - NO VALUE DELIVERED
  • Week Three - NO VALUE DELIVERED
  • Week Four - FINALLY, VALUE DELIVERED


It takes our developer until the middle of the fourth week to deliver any value to any customer. In our earlier scenario, the longest anyone had to wait was three weeks, and our first customer realized value after one! The task switching scenario is in all ways worse than the serial scenario!

So, how do we beat this [2]?

  1. If you must work on multiple projects, work on one at a time. Minimize the amount of context switches that you must do in a given time period to maximize productive flow.
  2. Your team may be required to handle interruptions, especially if you're responsible for supporting the software that you build. In these situations, consider rotating the responsibility for handling all interruptions for a week at a time. Make sure, however, that each person has all of the knowledge necessary to handle the interruptions. Otherwise this solution will quickly break down.
  3. Eliminate unimportant work and interruptions! If it isn't delivering value, stop doing it!
  4. Ensure that all of the knowledge necessary to complete assigned work is in the right hands. This will prevent the need to switch tasks by preventing the roadblocks caused by missing information.


That's all for this episode of "The Seven Wastes of Software Development." Stay tuned for the final installment: Defects.

References

[1] Poppendieck, Mary and Tom. Implementing Lean Software Development: From Concept to Cash. Addison-Wesley, 2006.

[2] Shore, Jim. "Task Switching." http://jamesshore.com/Articles/Business/Software%20Profitability%20Newsletter/Task%20Switching.html

Task (computing) Software development

Opinions expressed by DZone contributors are their own.

Popular on DZone

  • Building a Real-Time App With Spring Boot, Cassandra, Pulsar, React, and Hilla
  • How To Choose the Right Streaming Database
  • Full Lifecycle API Management Is Dead
  • gRPC on the Client Side

Comments

Partner Resources

X

ABOUT US

  • About DZone
  • Send feedback
  • Careers
  • Sitemap

ADVERTISE

  • Advertise with DZone

CONTRIBUTE ON DZONE

  • Article Submission Guidelines
  • Become a Contributor
  • Visit the Writers' Zone

LEGAL

  • Terms of Service
  • Privacy Policy

CONTACT US

  • 600 Park Offices Drive
  • Suite 300
  • Durham, NC 27709
  • support@dzone.com
  • +1 (919) 678-0300

Let's be friends: