Multiple Personality Development

In the context of LoneDeveloperProjectManagement, the useful technique of RubberDucking is hindered.

There may exist alternatives:

• TeddyBearing? - Explaining the problem to an inanimate object, which may have a similar effect to RubberDucking
• MultiplePersonalityDevelopment - Having a conversation with oneself

In MultiplePersonalityDevelopment, the developer must play multiple roles. Some common(simultaneous) roles are:

• The hindered programmer - The one with the problem
• The enlightened architect - The one that remembers and reminds things a code-jockey might forget
• The critic - The one who sees a problem in everything
• The radical - The one who has a very distant perspective, advocating a radically different approach.

In essence, the developers talks to themself as if it were a group conversation. It is arguably a mental illness, but may assist in development (isn't a lot of programming like that?). If the developer can sufficiently separate their personalities for the duration of the conversation, an effect similar to RubberDucking should be achieved.

---

Note: MultiplePersonalityDevelopment should not be confused with the MultiplePersonalityDisorder anti-pattern.

---

See: SixThinkingHats

---

Contributors: LayneThomas

---

I've done this all my life! (Seriously - only child, no kids my own age except at school, and I didn't really have any friends. Gotta find someone to talk to!) Sure, I get strange looks from people, but I constantly have devil's-advocate discussions with myself, ranging from the mundane 'where did I leave X' discussions to deeper 'okay, Joe, how are we going to build this system?' questions.

It definitely helps, though I find it's no substitute for having someone else around. It's a good way to, ah, 'think outside the box' (oh how I hate that phrase), but in the end, you're still working with your own personal resources, and yours alone. At the very least, it's a good way to widen your perspective - instead of thinking about the problem in the same manner you have for the last N minutes, you're taking on the role of a character, an actor in a play, and you need to behave how they would behave. Thus, as listed above, you need to try and imagine how, say, the System Architect / Guru would respond to a question, then switch roles immediately and try and come up with something zany that the Radical might describe. It's a helpful (if disturbing to watch) mechanism for looking at all sides of a problem and for leveraging your talents.

Essentially, it's a play-acting approach to the ChangeBrainstorm.

-- JosephRiesen