Refactoring Relationships

Working with people is a lot like working with code. New relationships are green fields. Over time they become brown fields and (just like code) they require maintenance. I’m sure that everyone reading this can identify some legacy relationships that they would describer as, well, complicated. Just like some legacy code.

working togetherI mean a lot with the word ‘relationship’. I have in mind everything from co-workers to friends to significant others. These variations all require maintenance and I think we should deliberately structure our relationships so that maintenance is easier.

Interaction Smells

So what is the social equivalent of a switch\case statement?

We talk about code smells in software development as suggestive indicators that something is wrong. In our relationships, it is interaction smells. I would consider these common emotional responses to be smells:

  • avoidance
  • irritation
  • suspicion

Personally, I have been guilty of avoiding someone because I thought I would irritate them and I didn’t want the hassle. This was in a work environment and it a negative effect on the overall efficacy of the group. My impulse to avoid was a smell and it led to a problem that needed to be addressed.

Amicability Debt

Bad code gets worse over time. We call this technical debt. Relationships that have soured do not get better by themselves. Little fractures grow over time. If we don’t address them when we smell them, the stink only gets worse. In addition, the stinky relationship can be begin affecting other parts of design, uh I mean, other social interactions (e.g., the team you are working with).

Refactoring the Relationship

Relationships are more difficult to work with than code for one primary reason:

You cannot revert back to the last revision if your changes fail.

Nevertheless, we often need to make changes. Refactoring code doesn’t change the exposed functionality, but we make internal changes to improve it. If you are beginning to have problems with your boss, that doesn’t necessarily mean it’s time to quit (change the function) rather you might just need some relational refactoring.

But what do I mean by refactoring a relationship? Well, there’s a lot to be said there and you can find a lot of practical advice on dealing with conflict and more over on “Doc” List’s blog.

In brief though, I mean this:

Be honest and humble. “Hey, Joe, I feel like you’ve been a bit on edge with me. Did I do something to frustrate you? I’d like to clear the air.” Then talk it over. Again, refer to Doc’s blog for lots of details.

I would like to qualify this further. Since you cannot revert what you say and do, you must be deliberate and thoughtful about your refactoring.

Afterword

You can see where my brain has been lately. It’s the cross-pollination of ideas from software development into all other human interests. Next week: multithreading and Italian cooking, followed up by ALT.NET and comparative religion.

If any of this resonates with you, you might be interested in (a possibly controversial) post regarding the maintenance of marriage on my personal blog.


Posted 08-08-2009 9:45 PM by Christopher Bennage

[Advertisement]

About The CodeBetter.Com Blog Network
CodeBetter.Com FAQ

Our Mission

Advertisers should contact Brendan

Subscribe
Google Reader or Homepage

del.icio.us CodeBetter.com Latest Items
Add to My Yahoo!
Subscribe with Bloglines
Subscribe in NewsGator Online
Subscribe with myFeedster
Add to My AOL
Furl CodeBetter.com Latest Items
Subscribe in Rojo

Member Projects
DimeCasts.Net - Derik Whittaker

Friends of Devlicio.us
Red-Gate Tools For SQL and .NET

NDepend

SlickEdit
 
SmartInspect .NET Logging
NGEDIT: ViEmu and Codekana
LiteAccounting.Com
DevExpress
Fixx
NHibernate Profiler
Unfuddle
Balsamiq Mockups
Scrumy
JetBrains - ReSharper
Umbraco
NServiceBus
RavenDb
Web Sequence Diagrams
Ducksboard<-- NEW Friend!

 



Site Copyright © 2007 CodeBetter.Com
Content Copyright Individual Bloggers

 

Community Server (Commercial Edition)