We had a classic case of design by committee at work last week as we discussed a naming convention for database columns. None of us are all that keen on dealing with disagreements on issues like this, although we still have the disagreements.
In this case, we agreed on the general aims of our naming convention and what we wanted to be able to express clearly by using it, but we had different opinions as to how exactly it should work. There were differences on the usefulness or otherwise of using underscores. We were agreed on PascalCase (i.e. capitalising the words and running them together), but there were differences over whether "is a" should be one word or two, when representing an inheritance relationship.
The details aren't important. We knew we had to arrive at a compromise and it was nearing the end of the day. Eureka! A little change here, a modification there and we had something everyone could reluctantly agree on, as everyone had given a little ground and accepted something they disliked.
Perhaps you can spot the error?
It occurred to me on the way home that I could offer a further compromise to qidane, one of the other disputants. I would be prepared to accept one of his preferences, in return for him accepting one of mine. You may think this sounds reasonable, but unfortunately qidane wouldn't fall for it. My "compromise" would have returned us to the original proposal before we'd had the discussions.
As it turned out, we were able to get to a much better compromise the next day - in fact, hardly a compromise at all - by agreeing to get rid of all the things we didn't like, rather than each accepting something we weren't keen on. This didn't bring us back to the original proposal, but positively improved on it, rather than building a Frankenstein's monster that none of us would have been happy with.
It is worth talking though differences to get to a better result, but it pays to take a step back once in a while to check you're making the right concessions!