If I was a builder, and there was a tool in my toolbox that I didn't understand, couldn't tell you what it was for, then I think that tool would stay in the box.  I wouldn't decide one day to get that tool out and start trying it out for jobs that I already knew how to do with other tools.  I might go out of my way to find out what it's for, of course, but until I knew, I wouldn't be trying to use it.  That's common sense I think.

Why then do we, as developers, often not apply the same logic to the "tools" at our disposal?  I've seen more cases of this than you might believe, but here's one that stands out because I saw it so many times...

Many years ago, I attended the offices of an ISV to spend 2 days training them on COM+.  I knew this ISV and I knew that they'd been using COM+ for at least 2 years.  It might therefore seem odd that they wanted training on it now, but "better late than never" I supposed.  I started by asking them some questions.

Me: "You decided to use COM+ then?"
Them (eagerly): "Oh yes, it was a no-brainer for our app, we knew we needed it."
Me: "Ok, who can start us off by telling me what COM+ is for?"
...Silence...
Me: "Well, you must have had a reason for deciding to use it?"
A lone voice from the audience volunteers: "Erm, transactions...?"

I can't be too hard on them.  I mean, I'm sure that distributed transactions are the reason why most COM+ users came to it.  It was a neat trick in its day.  But transactions are surely not the heart of COM+.  For me, it was all about the execution environment, the thread pool, the work queues, the ability to write STA components (in VB6 even) and have them run on a server.  Run quickly and reliably.  Whether they agreed with my answer to "what's it for?" is not the point.  The point is that they had made a clear decision to use a technology, without being able to explain what that technology is for.

I know people aren't machines, and applying too much logic to human behaviour never works, but there's a distinct lack of common sense here I think.  The reason I mention this stuff at all is that real software projects suffer and fail because of this sort of decision-making.  The builder analogy works again...

I can use a hammer to bang a screw into a piece of wood, if I hit it hard enough.  That doesn't mean a hammer was the right choice of tool.  Had I chosen the screwdriver, my life would have been easier, and the results would have been better.

Don't think that this issue is obsolete because I used an older technology as an example.  I still see it today.  You might also choose to blame the developer marketing people: if they keep trumpeting Silverlight loudly enough, some folks are sure to try and build a device driver with it.  I'm afraid it's our job as developers to see through the hype, and learn what all these tools are really for.