The #1 Software Development Post for Sep.'09

Best Dundies Ever - Pam (The Office)

Actually, I believe that on September 9th I read the best post for the whole year. Since I can't wait till December 31st, I decided to celebrate earlier, by handing out the "Best September Post" award. I am referring to Stephan Schmidt's The high cost of overhead when working in parallel piece.

Stephan's post argues that working on several projects in parallel is much less efficient than working one project at a time. He shows that by calculating the time spent on status meetings throughout the whole period. Typically, the scheduling of such meetings is based on calendar events (weekly, bi-weekly, monthly, etc.) and not on measured progress (because measuring productivity is hard). Thus, when working in parallel you will have more meetings for the same amount of project progress. As a direct result, you end up with a higher meetings/real-work ratio.

Stephan's bottom line, that working in parallel is less efficient than working sequentially, may seem quite trivial. Most developers already know that context-switching between projects incurs significant costs in time and mental energy. They know they are more productive when they can concentrate on one goal. They know that working on several projects is not-unlike juggling: you get to touch each one, but for very little time.

So, how come a post with a trivial conclusion is my #1 post this month? It's all about the argument. Stephan did a brilliant job taking a well known phenomena and providing a solid explanation for it. This is remarkable because most of the practices in the field of software engineering have only a vague explanation which often leads to endless, pointless, debates.

Even unit testing, which is clearly one of the most effective practices, has no real explanation. We do unit testing because it works, but there is no explanation as to how come testing your program against very few inputs dramatically improves its correctness with respect to an infinite space of "real world" inputs.

Stephan's post managed to do it. It supplies a rock solid, non disputable, easy-to-digest, explanation to a software development phenomena. This is not a trivial thing. Go read it.

3 comments :: The #1 Software Development Post for Sep.'09

  1. Wrong, of course...

    In my experience, the ability of a programmer to work on multiple tasks in parallel is a highly individual thing. A good manager will know how to allocate people accordingly: some will work on a single project, some on two projects, some on more, depending on both the people and the project requirements.

    Personally, I've worked on as much as four projects simultaneously, and have experienced a huge boost in productivity. Reasoning: bubble removal.

    Let me explain. Development is rarely done in a linear pipeline; there are dependencies between groups, people, features, and sometimes third parties (providers). Whenever, when working on project A, I find myself waiting for something, I immediately switch to project B. And so on. If I was working on one project, I would have had much more time to read email and update my personal homepage. But when multitasking, I can fill every idle moment with productive work. It can be a long wait (need a sample report from DataProvider to test and further develop the data processing pipeline; wait 2 weeks, do not pass "Go", do not collect $100) or a very short wait (waiting for a compiler; see http://xkcd.com/303/).

    I'm also rarely bored: when some task bores me, I move to another. And finally, when I encounter hard problems (design, algorithms, etc.) I often find that it's best to think about something else, and a solution will form itself in the back of my mind. Years ago, when I worked for Immensely Big Multinational corporations, I used to lean back and read a book until a solution presented itself. Now, I just switch to a different project and hack away. The total time to solve the problem remains unchanged, but the idle time is spent effectively.

  2. @Tal: "Whenever, when working on project A, I find myself waiting for something, I immediately switch to project B."

    I would suggest you take a look at lean and WIP.

    Cheers
    Stephan
    http://codemonkeyism.com

  3. I agree with Stephan. When a project is complex and requires an in-depth analysis if I only work on that project I will try to make difficult choice in little time. I can't spend one or 2 days simply thinking so I work on another project that is in an advanced phase and leave the hard questions in the back of my mind. Normally after a day or two good answers to difficult questions just bubble up in my head. With this approach it is very likely that my working days are more balanced, and that too affects productivity.
    Another plus of working in parallel is contamination: an optimization or a good idea or an elegant UI should contaminate also other projects or other section of the current project if possible. As a side effect this obliges me to refactor and remember my code, and, last but not least makes me care for them a little more.
    As for meetings, avoid them as much as you can.

    Giorgio

Post a Comment