[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?
