Back in the last millennium, when i was in college, i had a systems architecture prof that established my love of simplicity. He would frequently state the title of this post to the class, and we, young formulating minds would have only the barest inkling of what the hell he was talking about.
He had another statement that he made the very first day of class “There will be some day when you walk in on a workplace that does business with shoeboxes full of index cards. You’ll do your analysis and discover that for that business, the best method is to use shoeboxes full of index cards. Walk away.”
There’s a lot of wisdom in that statement. Yes, there may be more efficient methods from an objective point of view, but that’s missing the subjective point that if it’s not what the customer wants, they’re not going to use it.
That gets me back to the “Don’t craft solutions” bit. Basically, don’t become focused on the solution. It may technically solve a customer’s problem, but it may be more complicated, or require more time, or not quite work with all the bits that the customer didn’t talk about or think was necessary. You’d think that would be common knowledge, but it’s not.
It’s surprisingly seductive to become enthralled with what you believe to be the solution. Often, these solutions are so wondrous, that the folks crafting them never bothered to actually talk to the people having the problem. Hacker News is full of folks who have these kinds of solutions, and the rich history of failed startups they created. Heck, spend some time in the medical or manufacturing industry and you’ll see dozens of these “crafted solutions”. Any time you’re wondering why you have to give your information to someone multiple times within minutes, you’re experiencing one “crafted solution” after another.
And the poor soul on the other side is just as annoyed as you are about it, and you’re pride and joy of digital craftsmanship is going into the can as soon as possible.
So, yeah, solve problems. Understand the actual flow and requirements of a customer. Spend time talking to the folks who will be using your system and understand what they need and how they are planning on using it. Yes, it takes time. It means crafting those ancient relics called “requirements”. It also means that it may be weeks or months before you can start the fun of actually building something. Yes, there’s the possibility that someone else may craft a solution, but you’ll be able to point out how it’s deficient.
And, yeah, maybe they’ll actually use your system and wonder why they ever used shoeboxes before.