You have two engineering tasks, written on cards of course, on the same class. Perhaps one is to add a feature and another is to refactor the class. Perhaps you have two additions to do. 

The tasks clearly have much in common. Maybe you can save time by working on them both together, kind of changing methods as you encounter them.

Now of course if the tasks are very different, you wouldn't do this. If they are very complex, you wouldn't do this. But ''these two'' are so similar, it's more efficient to do them both.

Don't. Save your judgment. Just never do it.

Sit on one card, do one card. Complete it, then work on the second card. Always.

----

Note for the advanced student: the generalization step is to add to the cards you're sitting on, not the ones you're working on. ;->
----
''Never'' combine common tasks?
This runs counter to my experience (that sometimes it ''is'' a win).
Please say more.

----

The rule is '''Never'''. To be a win, the average time for doing multiple things at a time would have to be less than that for doing them seriatim. On the average, it isn't. The quality would have to be at least as high. On the average, it isn't. Over even the medium haul, relentless simplicity wins. 

Sometimes we break the rules. Sometimes we get away with it. Sometimes we even win. It's not the way to bet, if you're in this for the long term.

----

CommonSense tells you that this can't work because by combining two tasks into one you
will almost certainly spend less than the sum total of the time it would take
to do each task individually. But what CommonSense is missing is the fact that
when you sit on one card, the second task will always take less time than it 
would if it were done independently. There are several reasons for this:

	1. You can't keep the second task out of your mind while doing the first so you avoid complicating the second task and put in the occasional stub in preparation for the second task.
	2. When you start the second task, the details of the first are clear in your mind so your learning curve for the common parts is reduced.
	3. You will often be able to reuse some parts of the code done for the first task.

--MichaelDillon
----
I don't trust CommonSense.  Partly because what one person calls CommonSense, another person says is just plain wrong.  So what falls under CommonSense depends on the person speaking and the experiences that gave them their logic.  --AlistairCockburn
----
News flash: The C3 team renamed this rule SitOnTheOtherCards.
----
This sounds to me like the mandate given by HagbardCeline in TheIlluminatusTrilogy: NeverWhistleWhileYourePissing.

(I admit that SitOnOneCard and SitOnTheOtherCards are less potentially offensive.)
-----
See SitOnOneCardDiscussion.
----
CategoryCard CategoryProcessPattern