On promises made by marketing

In a large software organization, like in all large and complicated mechanism, friction always occurs at the interfaces.To overcome it, multiple communication lines are often erect between different functions. Take the army for example - while there's communication up-top, between the generals, often there is a lot of direct communication in the middle ranks and even more in the lower ranks. Doing otherwise would cause havoc on the battlefield - the air-force might bomb a location, but the message from the ground forces scout (that the target is long gone) is still en-route through the "official" channels.
In a software organization however, there's very little communication between the R&D department and the marketing department at the low ranks. Only the top managers - product level and upwards usually - meet with the people that actually meet the customers. This is usually excused by the need to "free the low-ranking R&D people (read-  the developers) from business concerns".
However, this lack of communication causes strange scenarios, where the marketing people don't really know what the product can and can't do and, even worse, don't know the future directions that can be traversed. Sometime only a tiny change in the code is required to enable a huge benefit (and a large increase in sales) for the customers. However, this request for change never comes to R&D because it's filtered by the marketing devision.
The same issue, only in reverse, occurs in the R&D department. Sometime we, developers, labor for days and months to enable a complex feature - that ultimately is used only by a small fraction the customers. Even more often, we over-develop - create a feature too wide in scope and too sophisticated - when the customer really just wants the simple thing done (usually over and over - and could we please provide some automation for that?).
Probably the worst sin of the marketing devision is committing to something that can't be delivered - or can be, but with great costs (development, architectural or performance). This is not done out of spite, though the complete effect does sometimes seem like the something done by an evil gremlin. The marketing devision truly wants to make the customers happy - but they lack the specialized knowledge the R&D personnel have - how exactly the product works. The worst sin R&D can make is barring (or even removing) features without really understanding the impact on the customer base. Again - not out of spite, but simply because no one has any idea.

The emerging pattern is of two disparate organizations - one dedicated for the "beauty and pureness of code", the other for "placating the customers" - while none is really dedicated for "create a product the customers want to use". This pattern especially visible the more "technological" the product is - the harder it is to actually understand the underlying logic.

On solving client problem - do you _really_ need to solve them?

[Note: Apparently my blog got reset. Not a big deal, since there wasn't very much there to begin with. Oh well.] [Note2: Apparently I got mixed up and opened another blog. Oh well - this one looks nice anyway :). The old one (with only 3 posts) is available here: http://www.jroller.com/objectpool]

[Disclaimer: this is a purely hypothetical situation]

T-17 days

"The customer is having problems with a specific flow. The support could not help - so it's escalated to R&D. Please advise".

What's more fun than starting your morning with such an email. Customer support. No - it's OK, we didn't have anything else planned for today - just some back-log of bugs, plans for the next version and maybe, just maybe, catching up on some unread emails. Oh well. Let's dig in.

T-14 days

"After investigating, it appears a sub-flow is not behaving correctly, suspecting performance issues, moving to team X".

We loafed around for 2 days (well - did some other stuff, not less urgent), met with the customer (online of course - no budget for flying), then whipped out the magic wand - it's a performance issue. Hooray for us! Let's make our customer prove their database, network and PCs are working as they should.

T-13 days

"Customer reports heavy disk activity during the problematic flow".

Oops. Someone smart is sitting there. Who's smart idea was it to log disk events?

T-10 days

"Investigation comes up with a problem in a specific sub-flow Z - takes too long, causing timeouts."

Yep - we finally found the problem. Apparently Z is causing a resource bloat. But why? (oh, the pun. I should be shot :) ). We have lot's of Z's in the system, why is this an issue?

T-7 days: "To team Y: Maybe you should execute Z'?"
T-6 days: "To team X: Maybe you should fix the Z?"
T-5 days: "To team Y: What's the big deal? It's not a big change in the code."
Weekend, no work
T-3 days: "To team X: We don't want to create a private patch for a single customer."
T-1 days: "To all teams: We have to fix this - what are the alternatives?"

T-0:

"We can change the Z just so... and it should now take about 0.1%  (yes 1/1000) of what it used to take (resources / CPU cycles)".

It's the first time someone from the technical side actually discussed the whole flow with someone from the knowledge side. And - surprise, surprise! The bloated result doesn't make sense. So they drill down a little further - "Ah - we should only ask what we REALLY need to." - "Oh - this reduces Z and let us preform some special optimizations on it - since we now know what should really occur".

---------------------------------

This sad story is fictional (I've changed team parts, mingled the problem and merged 3 different cases).
However, it depicts a sad truth in the industry.
We (software developers) are very technical people. We cherish our finely sharpened problem solving skills, our domain-specific knowledge and our advantage over "mere mortals". We rule the bits.

But we lose the big picture.

More often than not, what the customer really wants is not what we provide. It's close, and the customer can work with it - but he'd really rather get something else, simpler and easier to implement.

However, we're so caught up with our own technical wizardy and ability to "create a generic solution that'll apply to ALL customers from now until forever!" - oh, aren't we the greatest of all possible great things that can happen?

But we don't talk to each other. We don't really know what's wrong. We only know what's broken in our own part, and try to optimize our part, not considering it's only one link in a great chain - and often not the weakest link. It takes a great mental effort to take the holistic approach and actually see the issue for what it really is.

On your next support issue, I dare you to think twice. To look at what's really wrong and not at your own part of it. To truly understand what the user wants to do, and fix the root of the issue rather than the symptom

Then add some documentation - because after all, the user should've done "that" from the beginning - no?