The document tagging example has the pleasant feature of being purely technical: From the end user point of view it simply has no visible effect except that their themes suddenly get a lot better. So from their point of view no requirements have been dropped! So this advice is still useful even in the case where the external functionality is written in stone.

One way that can sometimes help with the client facing interaction is to simplify by separating. e.g. to take my silly coffee example “Well, I *could* build you a thing which does that. But how about I buy you a computer and a coffee maker instead?”. i.e. rather than trying to simultaneously satisfy the full set of requirements you offer to satisfy sets of them separately. But I must admit to having only limited experience with trying this in practice.

I also tend to solve the problem by evading it. These days I’m very much in the technical guts of the software rather than on the very user facing side. And I love it that way. :-)

1) You’re quite lucky in that you can push back on the requirements, as in your document tagging example. I’ve never been so lucky: the mere suggestion of simplifying leads the analyst/salesperson/customer/manager to begin to have epileptic fits, followed quickly by frothing at the mouth, fainting spells, and the stammering of thousands of reasons why the solution must literally be the hardest possible one or it will do no good.

2) Since no rationalization works for simplification of requirements, I attempt simplification by assumption-reduction. I try to treat problems like Sun-Earth-Moon problems, where I can ignore the effects of the moon to get into the ballpark then add it back in to improve my results. But, as I’ve learned the very, very hard way, in places where there “are” thousands of reasons for extreme complexity, every problem is an n-body problem.

I’m sure you’ve encountered these; how do you deal with them?

To be clear, I don’t deny your hypothesis that reducing complexity in the problem makes a linear-plus improvement in the solution complexity. It’s my strong agreement with it that leads me to continually bang my head against the walls of (1) and (2).