If there is one thing I've learned in my 11 years (holy crap 11 years?!) of developing software professionally it's that nothing is simple, not even the simple things.
I've come to understand that a big part of the reason for this has to do with the way our brains work. We're capable of holding different and inconsistent mental models of the world in our heads at the same time, switching back and forth between them, and we're not even aware of it. This is why when you ask a client, "how do you do <thing>?", they say "we do x, y, z", but later you find out that what they actually do is more like "if a then x, y, z; if b then y, z; if c then x, z; if d then w".
Sometimes we think our job is to discover and implement this complexity. But our job is actually more than that. Yes, we need to discover and model all that complexity, but our most important job is to then hide it away behind a simple facade, maintaining our user's illusion of simplicity.
And lest you blame this on stupid users, we suffer from the same problem when implementing algorithms! At least I do. This is one of the things I struggled with in solving the Word Ladder problem. I kept over simplifying the problem, which presented itself when my attempted solutions ran into some condition it didn't account for. Actually, I was lucky those solutions didn't work. Sometimes a solution that doesn't really understand the problem does work, but as the problem changes overtime, that solution rapidly degrades. It's the same issue, I allowed my illusion of simplicity to cloud the true depths of the problem.
Embrace the user's illusion of simplicity! Fight your own!
I would agree that many times what people *say* they do, is different than what they actually do. In many cases, though, our job isn't to simply translate what they say they do into software. It's our jobs to dive deeper - way deeper - and extract all of the smaller bits that compose into the larger need. By diving deeper, it helps to build a more solid foundation.
ReplyDeleteI think too often, we think our software is simple because it does what someone says - but we still haven't built the software in a way that adapts well to change. It's still a tangled mess - it just doesn't look that way because it meets the current goal.
Also, in my opinion, too many people use YAGNI as an excuse for writing poor software. They think that YAGNI means that they shove everything into one namespace, object, function, etc - because they may not need the little bits later. I think that's worse than premature optimization/abstraction.
Software isn't easy. And I have made some of the excuses I mentioned above - which is why I look back and want to punch myself in the face.
I am not saying that this is a magical fix, but I do think that developers often times shortchange themselves, create complexity, then later blame other conditions for why the software is hard to modify.