There is no one perfect thing

In this talk from Malcolm Gladwell, he discusses some interesting points about choice and the search for the one perfect solution.

Again, I can't help but think about certification and how we are trying to find a one size fits all approach to learning.

When I watch this I also think about why we often have problems when we ask customers what they want. Do they really know what they want? Are these things they want easy to articulate? Maybe a collaborative specification workshop with examples is what we need?

It's an old talk but a valuable one.


Good topic.

5 thoughts to “There is no one perfect thing”

  1. Hi Sebi,Thanks for commenting. I like the idea of using this for internal team structure. That angle hadn’t really struck me. Great blog post you did for it too.CheersRob..

  2. Do customers know what they want? Almost certainly not. Their understanding is constrained by what they already know and have, and find it hard to envisage what is possible.That’s summed up by the quote (apocryphal?) from Henry Ford; “if I’d asked customers what they wanted they’d have said they wanted a faster horse”.It’s the responsibility of developers, and business analysts in particular, to draw out hidden and barely understood requirements, then refine them. It’s not really like a hypnotist exploring the patient’s sub-conscious, but that’s possibly a more helpful analogy than regarding requirements as being no more than writing out a shopping list (which I have heard from a developer who believed that is what he should be doing).What’s the tester doing meanwhile? Possibly challenging daft practices (the shopping list mentality!), but also trying to find imaginative ways to help the business analysts and customers understand the requirements and refine them, and crucially doing it before the requirements specification gets baselined (fossilized) for the quality gate.That’s only half the message from the talk, however. There’s also the more obvious question of variability. It’s not something that traditionally software developers have taken on board, because development viewed functionality as a mechanical concept, even if it’s being carried out by a human. Traditional structured techniques treated humans as squishy machines, not massively varied individuals.

  3. Hi James,Very nicely put indeed. The shopping list requirements are a nightmare. I like the approach of working with the user to get some decent stories down. Stories help us make a little more sense of the facts (requirements) but there’s still an element of the unknown.Thanks for commenting. your comments are always more insightful than my posts :)Rob..

Comments are closed.