To usually my reply is "... well we are dealing with a complex topic..."
It's always interesting how it is easier to ignore complexity, than it is to try to understand it.
It's easier to ignore reality, than to see what really exists (or what is possible).
And the 'reality' will still be there, but if we ignore it, usually what happens is : Nothing!
Unless we are very lucky, it is very hard to solve a problem when we don't know what the problem is.
For me, the interesting questions are :
- "Is this 'complex thing' that I'm presenting an accurate representation of reality?"
- "If so, is it simpler than the previous version (or the current status quo)"
If the answer is NO, then its time to understand where the 'understanding gaps' exist, to modify the model/solution and to see if it still works.
If the answer is YES, then I'm happy that I'm on the right direction.
Now usually at this stage, the 'complexity level' is still too high, and maybe the target 'user base' is very small. But I believe that Simple solutions are a result of an continuous refactoring of complexity, until the 'right' solution 'just happens'.
So until we reach the "...now that's simple..." destination, its time to go back to the engine room and create the next generation of the working prototype (which hopefully will be simpler/less-complex and closer to the final solution).
Btw, one of my favourite moments, was when I was presenting (to a wider audience) an early prototype of O2's ability to visualise multiple SAST traces into one 'consolidated trace' and
... the first guy said (pointing at the screen) "THAT! is crazy!, this is far to complex and hard to use"
and
... the 2nd guy said (pointing at the screen) "THAT! is simplicity!, because I spend hours and hours to process the same traces, and don't even get to this level of understanding"
