Well, steveth45 is clearly clueless. Let's not adopt multi-tasking as yet another "proof" of the influence of cod on our daily life and our existence. If cod or a facsimile thereof even exists, which I personally doubt, then they are a fickle cod and hopefully will get over-fished to extinction by whatever "powers" dominate cod's surroundings.

That said, I think I agree with Jeremy Bowers in that people are able to multi-task (all people including us stupid, tunnel visioned, ego-driven, militaristic and generally evil hunter types not just the intelligent, caring and inherently good gatherer/child nurturer types). Last I checked, most of us (except steveth45) can walk and chew gum at the same time. Most of us can read a book and draw parallels to our life experience.

What is _not_ being said here about mental context switching while programming is the complexity of the code. Joel Spolsky's quote touches on this (but only at the negative side) when he says "A programmer coding at full throttle is keeping zillions of things in their head at once: everything from names of variables, data structures, important APIs, the names of utility functions that they wrote and call a lot,".

The _complexity_ of the code you are working within is perhaps the single most important factor in whether you can/can't context switch quickly. If the code is well architected, well designed with clean, cohesive components and classes, context switching is not very expensive. You move to a domain where the things in the domain accurately model the problem space; understand the problem and you understand the code. On the other hand, if the code is bailing wire, bobby pins and brute force algorithms, then the context switch can be huge.

One chunk of code we had on a project was so complex that, after some analysis, we determined that it took a developer about one full work week to ramp up to the point where they could fix a bug. Additionally, because of its complexity, if you left that task for a couple of weeks and came back to it, it once again took you 3-5 days to ramp up. This was code that was built with brute force logic, poorly cohesive data structures and with if statements to handle every bit of variable behaviour (as opposed to encapsulation with polymorphic or aggregated handling of behaviour).

This brings me back to Joel's quote - if the codebase _requires_ a programmer to keep "zillions of things in their head at once" then it (or more accurately, its creators) is at fault for the time a developer spends context switching.

The gut check here is, if it takes you or somebody else a long time to ramp up on your code, then odds are you're not a good programmer. Odds are you are one of the ones we laugh at when we consider the recent finding that "95% of all software developers believe they are above average". 45% of them MUST be wrong. To quote a line from Dire Straits "Industrial Disease" and a quote sure to please steveth45
"Two men say they're Jesus, one of them must be wrong".

Mr. Dudra is old enough to be able to carefully give the impression that he actually knows something, regardless of whether or not he does.

I also agree that treating developers like interchangeable assembly line workers is, for the most part, absurd. It goes to the whole mythical man month thing that given X units of work, if you throw N work units (a.k.a. developers) at it, you will be done in X/N time (although most development managers and RD directors seem to assume floor(X/N) - 10% for great management).

Unfortunately, it is a reality of the industry that people must switch projects from time to time. For this reason, it is imperative for managers to a) understand that there is a cost to this and factor it in - great management doesn't offset this (even when it is real and not imagined) and b) that developers must understand this and pursue the most readable, most cohesive and least coupled code they can so that the cost of a context switch is as small as possible. Saying "our code is complex; you can't switch me on and off of it like that" is paramount to saying "We are doing a bad job so it makes it very hard for us to go elsewhere and then come back to our substandard and difficult to understand work".

Sorry, no time to proofread - the lamb chops are cookin'.

Oh my god "I just admitted to eating MEAT!" Once again I shall be a pariah ...

I'm not disagreeing with you Paul.

A point I often try to make, and perhaps am trying to make here, is that legacy code is complex and difficult to maintain because it is _old_ code. As my former boss, Steve Adolph, once told me (and I paraphrase 'cause my mind ain't what it used to be),

"Every time you open up a piece of code and make a change, you leave damage. It is like operating on a person; each time you open them up to fix a problem, you leave behind scar tissue".

With enough changes to any codebase, it becomes old, fragile and brittle. Then it is painfully expensive to modify. True legacy code that has evolved over time cannot be prevented.

However, the point I am implying is that the vast majority of code is hacked out without design. Its design, if any, is at best some vague whiteboard scribblings and maybe a brief one or two page analysis of the sunny-day scenario where all goes well. Then, this "design" is encoded by people who all too often allow the debugger to do their thinking for them. I'm sure you've seen it and even done it (I know I have) - you write a for loop or similar construct and think "Gee, does that actually do want I want? I'll go through it in debug". Code built in this manner is code that NEVER had a chance to be young. It was born old, like those cloned sheep in England, because its birth was a long painful process of opening it up, hacking in a patch, and stitching it back together again. Before it is even released for the first time, it is a nightmarish twining of sphaghetti. It is that kind of "legacy" and/or "complex" code that I am suggesting should not occur.

Steve, I agree with you in that human beings (it's not just the software industry) tend to always gravitate to extremes - we aren't good at treading the middle ground and most "best practices" fall into the middle ground. For example, there is nothing wrong with socialism and nothing wrong with capitalism _unless_ you take either to the extreme - then they fail. But go to any financial district in the U.S./Canada and you'll find extreme capitalists - go to any university and you'll find extreme socialists.

Where I will disagree with you is your statement "They're used to coding in nested if statements and aren't really going to jive to a polymorphic command pattern" with its implication that nested if statements are simpler than a polymorphic solution (I wasn't discussing just the Command pattern - that is usually overkill for most tasks). If you are nesting a couple of if statements on a one shot occasion, you're most likely correct. However, too often an element of code has a set of state variables that, when interpreted, tell you what operations you need to do. There are also common tasks that must be done and you don't want to duplicate all that code. When the if statements become disastrous is when a program needs to repeatedly (for example in each method it enters) decipher the state variables to determine what special action must occur. Understanding that there are objects that specialize in specific behaviour and then calling those objects where appropriate is far simpler than constantly referencing these state variables and trying to a) remember what they mean and b) decipher the nested if/switch statements that select the appropriate behaviour.

All things in moderation is usually the best. If the differential behaviour is fairly simple and there is not a lot of it, use if statements. If the differential behaviour is significantly different and there are many cases where the different behaviour exhibits itself, use polymorphism. Everywhere in between those extremes you need to consider which option is best _BUT_ and this is a big but (with one 't' as opposed to what I am sitting on), if you are having a hard time knowing which is the correct decision, expect to have to change whichever decision you make at some point and build the system accordingly.

"Just my humble thoughts", he lies unconvincingly ...

One final comment on this, to perhaps clarify my words or to perhaps further villify myself.

I had this very discussion with a former developer today. You cannot rationalize that all projects must have a long bug fixing cycle or must be complex just because those you have worked on always do or, as this former developer said, because all the senior developers he talked to said that always happened. That is a fallacious argument in that it assumes that the development team is _not_ the problem. I would allege that in most, if not all those cases, it is the development team that is the problem - there are very few _truly_ complex applications but there are many applications that are _truly_ complex (if you get my drift). Failing that, I'll quote Albert:

"Any intelligent fool can make things bigger, more complex, and more violent. It takes a touch of genius -- and a lot of courage -- to move in the opposite direction."
-- Albert Einstein

Having been on fairly large scale projects that did not require lengthy bug fixing cycles at project end and did not become huge cumbersome, complex beasts that were nearly impossible to alter, I have personal experience that this need not be the case. However, having been on projects where developers had no overall plan save what was in their heads (and therefore virtually guaranteed to be different than what was in the heads of the rest of the team) and where those developers simply sat down and started to "cut code", I've seen that software developed in this manner _always_ ends up with a lengthy bug fix cycles and almost always ends up being complex, convoluted and headache inducing.

I'm not implying that Paul was saying this because I don't believe he was. Another rationalization for why a project resulting in bad code is "expected and normal" is that, since almost all projects that live long enough to undergo many revisions and become legacy apps (a very small percentage indeed) are complex and difficult to understand does not imply that all projects therefore will be complex and difficult to understand nor does it justify the argument that it is expected that projects become complex and difficult to understand right off the bat. Rather, it is a rationalization to allow us to believe we are really great developers even though our code sucks.

Finally, with respect to the statement about "allow the debugger to do their thinking for them". What I am trying to say here is that, when you are stuck in the gory details of some code and you are revamping a loop or a class because you just discovered it doesn't quite do the trick, it is nearly impossible to maintain a grasp of the complexity of that loop/class and keep track of the second order effects changing it will have on the code around it. By relying on the debugger to assure you your logic is correct, you are virtually giving up on trying to understand the first order effects of your code, let alone the second order. It is through design that we determine that the whole works as a unit - it is through code that we realize determine how the small units work and, as a consequence, realize the whole - at least that's how it should be.

Well that makes perfect sense to me but, as it is late, I will acknowledge that it might not make any sense to others.

jbn: Music may decrease your focus (and harm productivity) in _comparison_ to a perfectly quiet, distraction free environment. However, I think what the music listeners are suggesting it that it will have less impact on productivity than a noisy, open cubicle environment with Dilbert's overly loud guy in every cube around you and with flashing disco balls spinning ... (c'mon, how often do you get to talk about disco balls in a software setting - I couldn't pass that up).

In other words, to many people listening to music in their head phones is the lesser of two evils.

Nobody is saying managers are perfect. The next time I see a co-operative effort where one person involved is not, at least to some degree, at fault will be the first time I see that.

I love this quote "Many intractable tasks become soft and manageable after being simmered for a few hours."

If it _was_ intractable, it could not have become soft and manageable after a couple of hours of thought.

So, why do I love this quote? Not because it allows me to point out somebody's illogic but because it goes to the heart of _everything_ I've been trying to say about design vs. hacking.

What shavenwarthog (good name by the way) is probably saying is "often a task that _seems_ intractable can be solved by thinking about it, even sub-consciously, for a few hours". This statement I agree with fully (especially since they are my words attributed to others - like a god shoving thoughts into the heads of my minions)

The problem with hackers is that they run into these _seemingly_ intractable problems and just dive into them, solving them in the first manner that occurs to them - usually the most brute force approach that could be envisioned. Generally, when doing this, they are not building a simple throw away test app or creating new code; no, they are modifying existing code while they do this so the damage their bad, brute force solution causes ripples through the codebase as they tweak things here and there to make the poorly analyzed, poorly considered idea work.

In this case, a context switch to let your sub-conscious work on the problem (remember, it uses 90% of your brain and your conscious uses 10%) instead of your conscious mind allows you to think through the problem which is, after all, step 1 in design. Then all that remains is to record the design so others can comment/review and later learn about what you are proposing. Doing the design is yet one more way of forcing you to _think_ about the problem instead of hacking out the brute force solution.

Now the comment by buggyfunnybunny of "I've always been amazed that folks don't find the existence of the Sequence Diagram in UML just the teeniest bit ironic (well, dumb): a fig leaf to cover the proceduralness of what OO designers are really doing.".

I promise to think about this one since I've never thought of the sequence diagram that way. However, my initial reaction is to disagree. Sequence diagrams that show purely procedural code are lousy - they don't design anything since you make call "Foo()" to object "Blee" and then it returns. The reader has no idea what went on inside Foo or what effect it had on Blee or the world around Blee. A well done sequence diagram shows how multiple objects, each with its own areas of expertise being exposed by their contract with the world, _co-operate_ to accomplish a common goal. It is, in that sense, OO in its purest form.

I forgot to add:
The flow of a sequence diagram and the flow of procedural code are only similar in that each illustrates actions over time. Time being one of the critical dimensions in my universe (and likely yours). The flow of time is something that every system must address. Without addressing the passage of time and events across time, the system doesn't really model anything in the real universe.