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