It's human nature. People need to first understand why the "wrong way" is wrong, before learning better ways.

They don't understand your ideea from the beginning because they are greedy and don't want others to think that they couldn't come up with such great ideeas

Often, the reason for question is because the solution looks more convoluted than it needs to be. The team at H thinks it should be much simpler but they don't realize the other team thought the same thing back at I, J, or K and ran into problems.

I think this is what impedes adoption of things like NHibernate. People can see a solution to data access in their heads already because it's all over the Microsoft demos. And it usually looks a lot easier than NHibernate. But they haven't encountered (or acknowledged) the issues that led to others adopting NHibernate.

Pingback from  My Idea is Awesome « Frontier Label Tech Blog

Unfortunately, developing software is one of the areas where problems similar to the one you've outlined will continue to arise.  To some extent, it's rather easy to fall into this trap (although perhaps more so in the early stages of learning software architectures).

An oversimplified example is when someone who has not yet embraced patterns looks at say, the implementation of logic utilizing an abstract factory pattern rather than an if/else, switch, etc.  The immediate question is "Why go through all this when I can just use an if/else?"  Naturally, there are multitude of reasons for doing so - which I won't even go into here.  But the point is that to really be good at what you do (in many industries, including ours :) ) is you need to *anticipate* what is unknown at the time you write something.  I think this relates closely to your point about explaining I-Z simply because you've taken idea H and evolved it.  The evolution of (and progression of what happens when you follow path H, I, etc...) is why you land on Z.

All in all, I'm just saying this is a good post that I agree with albeit in a very verbose fashion :)

Interesting... contrast this to the recent post by Jeremy Miller, titled A Coalition of the Willing:

codebetter.com/.../a-coalition-of-the-willing.aspx

don't know why but that post came to my mind.

I wouldn't say there is a contrast between the two posts, in a way they support the same thing.  Jeremy's was more about "what happens after I explain I to Z and someone still refuses to accept the solution" aspect of the problem.

I guess, if anything, they just were in the wrong order.

@All,

I don't disagree with Ian at all, and I think he's spot on here.  I just think that there are plenty of folks that are just never going to agree with us (as if we really agree with each other all the time), and we should accept that and move on.

Every hour you spend trying to convince somebody to do things your way is an hour you're not spending making your way better.  Just decide which side of that statement adds the most value.

@Jeremy

You're right, but sometimes people aren't going to agree until they understand. They still need to be willing though.

I think it's pretty presumptuous to assume your solution is "smart".  As logical thinkers, programmers know that there are many paths from I to Z, and many more that _look_ like paths from I to Z.  Having to explain _your_ chosen path not only validates to others that you have created a correct path, but also gives them an opportunity to optimize that path.

It might be a pain to some to have to explain their solution to others, but it's very rude to simply tell someone that your solution is not only correct, but "smart" as well, hoping to end all discussion there.  Let them draw their own conclusions.

I had an disagreement recently with a developer who wants to convert the world to TDD. What you are saying is exactly the point I was trying to make to him. You can't convince a person of a solution until they have experienced the pain you are solving and they have the prerequisite knowledge to understand the solution.

Totalmente acertado. Además, todo se basa en el concepto de las cosas, en la idea. Es fundamental que se analicen bien los pros y los contras antes de pasar a la acción. Pero una vez tomada la decisión, el método de ejecución de la idea es tan importante

Hello,

Please add your site at http://www.sweebs.com. Sweebs.com is a place where other people can find you among the best sites on the internet!

Its just started and we are collecting the best found on the net! We will be delighted to have you in the sweebs listings.

Regards

Kris

Team

WhereThere'sPeople,There'sProblemswww.noop.nl/.../where-the.html

Teamsareth...

v5XavQ

YiSohp

A classic (and effective) method in pedagogy is to start with a problem, then show progressively more advanced ways of handling it until reaching the (current) best practice.  (One well known example of this is how Don Box explained COM as a natural evolution of object design.)

If people understand the core ideas behind a concept, their buy-in will, of course, be maximized.  Sometimes, however, a command-and-control approach is needed to increase the short-term efficiency of the team and move the project forward.

The big question of politics (public or private) is how to achieve the most effective balance between getting everyone on board versus the ability to take decisive action, while at the same time ensuring that the system cannot be abused for the benefit of a few, at least in the long run.