The "Joys" of Software Development Specifications

I'm finding the lack of decent specifications at work at the moment somewhat frustrating. I have thought of a way to describe what's actually happening.

A typical sequence happens something like this:

Sales/demo rep:

We need a piece of string. We have to be able to hang something using it.

Oh, and we need this implemented within 2 weeks for a demo...we've already said you'd be able to do that - it's just a piece of string, after all.

Programming team:

That's not a lot of detail - what exactly do they want to hang on this string? How long do they need it? How are they going to be using it?

Sales/demo rep:

The customer isn't sure - it's just a piece of string. Just work it out yourself - it's not that complex after all. We provide solutions for customers, not problems.

Programming team:

*implements a string for hanging something, tests it by hanging pictures around the office*

Sales/demo rep:

This string is too short, it has to be longer - we've heard that the client has a high roof. And we can't just tie two strings together in the demo, because it's clumsy/awkward and the knot may slip. It will look bad.

Programming team:

*reimplements/extends the current design of the hanging string, so that it accounts for a longer-than-expected string being required. Test it by hanging things from the office window, since the office is a few floors above the ground*

Sales/demo rep:

When we hung up the bag of bowling balls that we're going to be using to demonstrate hanging things with this string, the string broke. It's not strong enough to be usable.

Programming team:

You want to hang a bag of bowling balls from it? We never expected that kind of weight!

Sales/demo rep:

Why not? We said it had to be suitable to hang something with, and a bag of bowling balls is something. Why wouldn't you design it to handle that kind of weight? How can we say it's suitable to hang things with, if it's going to break when someone uses it to hang heavier things?

Programming team:

*reimplements the string using a rope, and tests it by hanging the bag of bowling balls from the office window*

Sales/demo rep:

This string/rope takes up too much space when we store it - it's going to be hard to carry to the demo. It needs to be thin and light, but long and strong - and we'd prefer it to be red instead of tan coloured.

Programming team:

We're pretty much out of time here - why couldn't you have specified any of this upfront! And you're carrying a bag of bowling balls to the demo, but you can't fit a small coil of rope? *scrambles to adjust things for the demo by painting the rope red, and splitting the rope in half lengthwise - which makes it look a bit frayed/frazzled but it's the best they can do in the time left, really wishing they could hang either themselves or the sales rep from the currently implemented rope instead, and verifies that it still holds the bag of bowling balls from the office window*

Demo occurs. Sales/Demo rep's feedback:

The demo was a failure because the string didn't do what the client needed. All that client needed it to do was hang a balloon from a picture rail. It was too complex/heavy/long/expensive for what they needed. We don't understand how the programmers could have screwed up the implementation of a simple piece of string to hang something with so badly...why do programmers always want to make simple things so complex?

Oh, and that shade of red clashed horribly with the customer's teal balloon.