Sponsored By Aspose - File Format APIs for .NET

Aspose are the market leader of .NET APIs for file business formats – natively work with DOCX, XLSX, PPT, PDF, MSG, MPP, images formats and many more!

Why people do not see how smart your idea is at first

One of the ‘features’ of my current project is that the development team are seperated by the Atlantic from the analysts. So we have to learn overcome the resulting communication issues. One observation that we have from that experience is why other people do not always ‘grok’ your new great idea.

A scenario we experience commonly is that the developer team and the analysts begin discussing a problem in the shared working hours of the day. During our shared time we may move from steps A-H of solving a problem. But in the interim one team or the other may take a way the problem and keep working on it and take the problem from I-Z reaching a conclusion. When the team meets up again, the team that continued working on the problem presents their solution Z (usually with a drum roll) in full expectation that the other team will laud their clever solution.

But what usually happens is the other team start asking questions. Why would you do it that way? What was wrong with this solution? Often the presenting team are dissappointed and furstrated. Why don’t you get my beautiful idea? Why don’t you just accept what I am saying to you?

The problem is of course that one team is at H and the other is at Z. You can’t just skip all the steps in between. The team presenting has to walk the team that need to catch up from I to Z so that the lagging team can understand the reasoning that led to their conclusion. As my math teacher used to say: show all your working.

As a community Alt.Net often experiences this problem. We leave the path everyone else is on at H and run all the way to Z. When we come back and tell everyone else that Z is now the way to go, there is questioning and disbelief, because we left the broader community at H. If we want to communicate effectively we have to summarize I to Z.

The Peristence Ignorance conversation at Alt.Net Seattle was a great example of this. You cannot just present Persistence Ignorance and expect folks to adopt it. You have to explain what steps (testability, seperation of concerns, single responsibility etc.) lead you to prefer persistence ignorance and how tools that do support it achieve that.

Of course we could put our head in the sands and just say it’s up to the rest of the community to work through I to Z, but too often we do not document our footsteps well enough for others to follow in them.

About Ian Cooper

Ian Cooper has over 18 years of experience delivering Microsoft platform solutions in government, healthcare, and finance. During that time he has worked for the DTi, Reuters, Sungard, Misys and Beazley delivering everything from bespoke enterpise solutions to 'shrink-wrapped' products to thousands of customers. Ian is a passionate exponent of the benefits of OO and Agile. He is test-infected and contagious. When he is not writing C# code he is also the and founder of the London .NET user group. http://www.dnug.org.uk
This entry was posted in Uncategorized. Bookmark the permalink. Follow any comments here with the RSS feed for this post.
  • Scott Taylor

    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.

  • http://peanjroz.com/ Xixpovsl


  • http://nmvvjysv.com/ Moxuhxqg


  • http://www.sweebs.com Kris


    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.


  • Ian Cooper

    @Jeremy @Jiho

    I agree that Jeremy was talking about something different.

    As an example it has taken time for me to warm to context/specification. What helped me was seeing Scott Bellware present on it at Alt.Net Seattle 2008 and his article in Code magazine.

    But I was willing to accept that Scott knew something I didn’t, but I had to see more steps to understand what it was.

    Jeremy’s issues seems to be that if, having explained the working to me, I still refuse to work that way, that’s up to me, and really we should just let it lie.

  • Ian Cooper

    Well I think you can short-circuit the process, sometimes, by running through the scenarios that led toward TDD (everyone needs to test their code, wouldn’t it be easier if the tests were automated, wouldn’t it help to know what needed to pass before writing incorrect code, wow i get design insights from specifying what I want).

    The trick is to be able to remember the steps you took, often we internalize them so much that we forget them.

  • http://hackingon.net Liam McLennan

    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.

  • andreP

    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.

  • mendicant


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

  • http://codebetter.com/blogs/jeremy.miller Jeremy D. Miller


    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.

  • AndrewLV

    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.

  • Jiho Han

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

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

  • http://www.geeksWithBlogs.net/SanjayU SanjayU

    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 :)

  • Kyle Baley

    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.

  • http://tinyurl.com/dfbu9u YanYg

    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

  • http://hadihariri.com Hadi Hariri

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