The hidden costs of the multi-tasking software developer

By Sean McGrath, ITworld.com |  Development Add a new comment

We software developers work with words for a living. We have words for everything. At the drop of a hat, we will appropriate an existing English word/phrase and bend it to some new purpose. Words like "function" or "service" or "filter" for example. Phrases like "load balancing" or "multiple inheritance" or "context switching"...

Hang on a moment. That last one is a bit different I think. Back up the truck a little here. The flow of language I speak of is not all one way. There are times when the software world has a word/phrase for something which flows from geekdom into the mainstream. This is one of them I think.

Yesterday, a colleague complained that the timesheet system we use at my day job does not have an entry for context switching[1]. The geeks in the room knew immediately what she meant but everyone else was baffled.

The phrase relates to a common computing concept of a single CPU juggling many tasks at the same time. In order to give the illusion that lots of things are going on at the same time, the CPU jumps very quickly between a bunch of separate tasks creating the illusion of parallel activity.

Obviously, for this to be an effective strategy, the time it takes to switch from one task to another, is critical. This process is known as context switching and CPUs typically do it very, very quickly indeed.

For human beings however, context switching is a much, much slower process. Consider a software developer working on multiple, distinct projects at various times. If the a.m. is to be spent on project A, that can easily go into the timesheet. No problem. If the afternoon is to be spent on project B, adding that to the timesheet is a little more problematic. The problem arises from the non-trivial amount of time it can take to mentally switch from project A to project B. The time involved can be anything from minutes to hours and even days.

Over the course of a year, this time can really add up and it can be infernally difficult to explain to non-technical folk why context switching can be so time consuming. In extreme cases, developers can spend more time context switching between projects than they do actually making progress on any project.

Which brings to mind another phrase us developers like to use -- a "disk thrashing"[2]. This occurs when there isn't enough memory and stuff needs to be parked to disk only to be hauled in again, the next time the context switches.

It is easy to spot when this happens as the machine tends to make unpleasant whirring noises and flash red a lot. Come to think of it, this is often the best way of spotting developers caught in endless context switches too.

[1] http://en.wikipedia.org/wiki/Context_switch


[2] http://www.webopedia.com/TERM/D/disk_thrashing.html

    Add a comment

    Post a comment using one of these accounts
    Or join now
    At least 6 characters

    Note: Comment will appear soon after you have activated your account.
    Obscene/spam comments will be removed and accounts suspended.
    The information you submit is subject to our Privacy Policy and Terms of Service.

    ITworld LIVE

    DevelopmentWhite Papers & Webcasts

    White Paper

    HP NonStop SQL Fundamentals whitepaper

    This whitepaper offers a detailed look into the fundamentals of HP NonStop SQL solutions. See how this system delivers unprecedented levels of application availability with fail-safe data integrity and meets the needs of enterprises with large-scale business critical applications.

    White Paper

    Nebraska Medical Center case study

    See how the Nebraska Medical Center implemented a SQL solution to make information more readily available to streamline operations, improve patient care and facilitate medical research with an enterprise solution running on HP NonStop servers.

    White Paper

    Concepts of NonStop SQL/MX

    For DBAs and developers who are familiar with Oracle solutions and want to learn about NonStop SQL/MX, this whitepaper provides an overview of the similarities and differences between the two products-with a specific focus on implementation.

    White Paper

    6 Things Your CIO Needs to Know About Requirements

    If your organization is not predictably successful on technology projects, there is likely an issue in requirements. CIOs must take action and own requirements maturity improvement. There are 6 main things a CIO must know about requirements.

    Webcast On Demand

    User Experience Monitoring

    In this webinar, you will learn hints & tips for improving end-user response times from Forrester Research analyst, Jean-Pierre Garbani.

    Sponsor: Nimsoft

    See more White Papers | Webcasts

    Ask a question

    Ask a Question