Book Review: Dealing with Difficult People

For those of us in technical roles, I think too often skill set becomes equated with technical skill set. The fact is non-technical or soft skill sets are beneficial to people in technical roles. Soft skills involve your ability to communicate with others via e-mail, the phone, and instant messaging but also via articles, books, conference presentations and blogs.

The importance of working well with others is amplified in Open Source projects like Eclipse. Eclipse projects tend to be developed by large, geographically dispersed teams. These teams are comprised of people with, among other things, very different backgrounds, cultures, expectations, and priorities. These differences are further highlighted by the fact that the people on the project come from many companies and organizations meaning management structure cannot be used to enforce project decisions.

With that in mind I'd like to take a look at a book I just finished reading by Dr. Rick Brinkman and Dr. Rick Kirschner entitled "Dealing with Difficult People: 24 Lessons for Bringing Out the Best in Everyone".

Let's get the details that may prevent you from looking at this book out of the way. The book is very short, weighing in at just under 100 small pages, and can easily be read in a single sitting. (I'm not a quick reader.) And, the book's cheap going for ~$10 on Amazon. Now, on with my review.

As you've likely guessed from the title, the book focuses on dealing with difficult people. These people show up at work but also in all facets of life.

In order to deal with a problem you have to know what you're dealing with. In its coverage of difficult people the book starts with an quick overview of the ten most unwanted behaviours: the Tank, the Sniper, the Know-it-all, the Think-they-know-it-all, the Grenade, the Yes Person, the Maybe Person, the Nothing Person, the No Person, and the Whiner.

With the question of "what" out of the way the book then moves on to the question of "why". Why is this person being difficult? According to the book, the motivation of a difficult person revolves around four intents. Understanding these four intents is key as once you understand the reason someone is being difficult you can work to resolve the problem in order to remedy the difficult behaviour. This part of the book should make it clear that difficult behaviour is a manifestation of another problem and once that problem is understood you can work to make the difficult person a productive member of your team.

Empowered with an understanding of who you're dealing with and what motivates them, you are ready to attack the problem. The book then presents you with a deeper view of each type of behaviour and arms you with tactics to combat each type of difficult person.

While the book focuses on identifying difficult behaviours in others I found a secondary benefit was the ability to look inwards and discover ways in which I can and have been difficult. It's not always easy to solicit negative feedback from peers and I think this book is a good tool for looking at yourself to discover some of your own negative behaviours.

Technical people need soft skills along with technical skills. Soft skills are a key component to the success of Open Source projects like those hosted at Eclipse. "Dealing with Difficult People" is not an in depth tour of the human psyche. It is a quick read that will open your eyes to the way both others and you behave and build upon your soft skills enabling further success in your projects.

Eclipse Reaches out to Apache

As Bjorn and Ward announced on their blog, Eclipse recently extended a sweet invitation to Apache committers to attend EclipseCon. The sweet part of the invitation is that Apache committers can attend the conference for the Eclipse committer price. (If you're an Apache committer simply go to the EclipseCon site and register as a committer.)

As a committer for both Apache and Eclipse I was personally very happy to see Mike Milinkovich's invitation sent to the Apacahe committers mailing list that stated,

"As you may know, a number of Eclipse projects implement tools for Apache projects and in turn, many Apache projects are using Eclipse technology."

This statement shouldn't surprise those working at either Apache or Eclipse but I think it serves as an official recognition of the growing synergy between two of the most prolific open source communities. Although these two communities do differ their interests continue to align through their various projects.

In his invitation Mike also said,

"We really appreciate the support the Apache community has extend to Eclipse and we look forward to building closer relationships."

I couldn't have put it any better. Bravo to the Eclipse foundation for making a real effort to bring these two great communities closer together.

To SVN or Not to SVN? That is the Question...

Last week Denis Roy, the Eclipse webmaster, announced on the committers' mailing list that Eclipse has installed Subversion (SVN) and that Eclipse projects can make the switch from CVS to SVN if they choose. This leads naturally to the question should your project make the switch and, if so, is now the right time?

Before undertaking a project such as migrating to SVN it's a good idea to perform a cost/benefit analysis. So let's start with that.

The following is my list of the key benefits of SVN (a more complete list is available from the SVN project website):

• File history is maintained even when files are moved or renamed. This means when Joe, a refactoring whiz, takes a cut at your code you'll still be able to view your comments to give you an idea of what's what. As anyone who's moved a file in CVS knows, when a file is moved in CVS its history is left behind and it's difficult if not impossible to locate later.
• Commits are atomic. This means a commit only succeeds if the entire commit succeeds. (CVS has a nasty habit of having part of large commits succeed.) It also means revision numbers and comments are applied uniformly across all of the resources that were committed. So the next time you do a large commit that fails in the middle you won't have to sync and manually figure out what still needs to be committed.
  
• Branching and tagging take a constant amount of time. This can make a huge difference when branching or tagging a large project and means you can continue to work instead of waiting for the operation to complete and possibly getting distracted by the latest argument on Slashdot.
  

And here are some of the costs of migrating from CVS to SVN:

• Someone will have to migrate your existing CVS repository to SVN. Although Denis has offered to help with the migration this will still require Egon, one of your project's developers and a member of the release engineering team, to spend time on migration, time he would otherwise have spent on activities that will affect the project deliverable like fixing medium and low priority bugs.
  
• Your project's developers will need to learn SVN if they're not already familiar with it. This may not seem like a big deal as SVN is very similar to CVS in many respects but it will take a non-zero amount of time, especially when installing (someone's bound to run into problems) and learning to use the tools (which are not the same as those of CVS), and again takes away Egon and other developers' time to fix those bugs.
  
• Furthermore, the current SVN tools for Eclipse are not available from Eclipse but from Tigris through the Subclipse project. Some employers have strict policies on using third party tools and Daina, a developer working on the 'cuddly' feature, may need to seek approval from her employer to use the available SVN tools. (There is currently a proposal for an SVN team provider project but that has not yet been approved.) This means Daina won't be able to contribute changes because she can't use these tools until they've been approved by her employer.
  

OK. So there are some real benefits, although my experience with SVN is that I didn't see these benefits on a day-to-day basis, and there are some costs, the size of which will depend on your specific development team but will always be non-zero for existing projects.

Let's take a look at one other aspect of this migration project. I've been reading Joel Spolsky's book Joel on Software so let's take a lesson from Joel and look at this change from a consumer (that's Eclipse user or adopter) perspective instead of a developer perspective. What will your consumers gain from the switch from CVS to SVN?

Nothing!

This switch will not reduce the development time, add more functionality, fix bugs, or improve the testing of your project.

So, to me this is now a question with a simple answer. No. It's not worth the time to make the switch from CVS to SVN now, in the middle of your development cycle, as this switch will provide very little benefit to your project. Also, this switch will not benefit your consumers who, in the long run, will determine whether or not your project is successful.

Are you saying no Eclipse project should ever switch from CVS to SVN?

No. I don't want to suggest that all the Eclipse projects should stay with CVS forever. As I listed above, there are benefits for developers in using SVN instead of CVS. These benefits do have an initial cost that I don't think is worth paying in the middle of a development cycle, given that there is so much more important development work to do, but may be worth paying at the beginning of a development cycle. Making the change at the beginning of the cycle will allow your team to respond to problems early and should mitigate schedule slips later on in the cycle when you have less flexibility. Also, if and when the SVN team provider project is approved and produces tools that come with Eclipse this will remove the third cost listed above. With this in mind, if your project does want to make the switch I'd suggest holding off on it until after Europa (the next Eclipse release train scheduled for June) or whenever your next major release happens to be.

Defining the Eclipse Brand

Over the last few years Eclipse has experienced more than significant growth and has expanded well beyond its, what seems now to be modest, Java IDE roots. Eclipse now hosts 10 top level projects that contain 90 (if I counted correctly) combined subprojects with 11 project proposals currently sitting in the pipeline. The addition of each new project has broadened Eclipse's scope taking Eclipse in a new direction. The Eclipse community is thriving. Many great projects are being produced. But has the Eclipse brand, that is the name "Eclipse" and what it represents, grown along with Eclipse itself?

Take a moment now to answer this question yourself. Sit back, relax, and think about Eclipse. What's was your first thought? Was it Eclipse the Java IDE (aka JDT), SWT, or RCP? How about eRCP or DSDP? WTP, DTP, EMF/Modeling? Perhaps BIRT, SOA, or the ever popular Mylar? Or did you think of the Eclipse foundation?

My answer to this question continues to be Java IDE, SWT and RCP. This despite the fact that I'm a WTP committer and previously worked on the now graduated WSVT project. Comments such as this one (by mmm, try to ignore the negative aspect of the comment) show that I'm not the only one with this Eclipse brand baked into my head.

This type of brand problem isn't a new one and isn't one that's going to end with Eclipse. Let's take a look at two other projects, one that has already experienced this problem and one that looks poised to experience it as it begins to grow.

Apache started as the Apache HTTP server and I'm convinced that many people outside of the Apache community still think HTTP server when you say Apache. Of course today Apache is one of the largest open source projects in the world with numerous influential and ubiquitous projects such as Ant, Maven, Struts, Tomcat and Xerces. (I'd say that Woden, the Apache project I work on, has not been adopted quite universally yet.) And let's not forget Harmony, the Apache implementation of Java, which although not complete has already garnered much attention. Apache has experienced the same brand problem as Eclipse and it looks to me like this project has (perhaps unofficially) adopted a wait it out strategy assuming that one day people will get that Apache is more than the HTTP server. At present I think that the Apache brand has made some progress but it's difficult for me to gauge how much progress being part of the community.

Dojo is a fairly new project that started out, like Apache and Eclipse, with one key project: The Dojo Ajax Toolkit. Many people have heard of Dojo but I think most don't know that Dojo is also a foundation (like Apache and Eclipse) and Dojo currently hosts two subprojects: OpenRecord and Cometd. Dojo hasn't yet hit that critical point when rapid project growth begins but I think they're positioned well in the Ajax space, have the backing to survive the Ajax toolkit wars (I just don't see how two years from now we'll still have 100+ Ajax toolkits available), and therefore have the potential to grow their project base and scope. I don't think the Dojo Foundation has given much thought to the topic of the Dojo brand at this point but it will be interesting to watch and see how it tackles this in the future.

Looking at these two examples I don't think we, as the Eclipse community, have much strategy we can borrow. I think there is a lesson for new open source projects and that is building the brand of your open source organization on the name of its marquee project has shown that it can lead to confusion with respect to the other projects your organization hosts. I don't see a good solution for this as when forming an organization you want to cache in on the name recognition already in place. This lesson, however, seems to me like something that can be filed under good to know when forming an open source organization.

So what can we, the Eclipse community do to grow the Eclipse brand? I think we need to increase cooperation among the various Eclipse projects to create value add of using multiple projects together - something I don't think we're doing a very good job of today. In this way, when people think of Eclipse they won't just think of one project because they won't use just one project. They'll buy into the benefits of using WTP, DTP, ATF, Dali, and TPTP together. They'll explore the update site to discover other projects that will enhance their current tools. And once they see all of the projects as a single Eclipse offering they'll get Eclipse and the brand will grow.