All solutions address a need, all true solutions. In practice many so called solutions ease a need, or counteract the effects of a need. Addressing a need directly can be a surprisingly difficult task. Sometimes, when there are external pressures and restraints upon your actions, the best you can really hope for is to find the most effective mitigation for that need.
It's not always easy even to distil the nature of a need. In fact, it's far easier to get a sense of the need through identification of it's symptoms than to truly get to the root of what is lacking. Rare are the times when the problem is succinctly identified by serendipity, it takes analysis, discipline and often a measure of intuition.
An example might be a software service that interacts with a legacy system. What I really need is a direct route of communication to that old but robust backend. What I have to create due to the limitations of that legacy backend is actually a relay that sits on an intermediate layer of the architecture. My solution is indirect, not the optimal solution.
Another example might be that I need to communicate a complex infrastructure issue to the guy (or gal) at a partner organisation. What I really need is to have lunch with this person, but the bureaucracy of communication dictates that actually I send an e-mail to the designated point of contact and hope that the information makes it to the right pair of eyes intact and understood.
Maybe I want to attend a music festival in a relatively remote corner of the country from me. The ideal solution would be to pack the car and drive there, but the constraints of my budget mean that I have to make a long train journey with slow and often numerous connections.
I have years worth of project documentation and paperwork to store. The ideal solution is to digitise, the practicality and sometimes the legality of the situation mean that I have to invest in secure, long-term storage for the physical document. Time constraints mean that I don't necessarily have the hours available to perform the required scanning or data input. I may even only be deferring the task (at mine or my employers expense) to another time or another poor soul.
Life often does not allow for the ideal and elegance hinted at by Marcus in the quote above. That doesn't mean that we shouldn't try to achieve it. Sometimes... often... it's almost always more expensive in terms of resources, be that money or someone's time, to arrive at an ideal solution. Occasionally it can't realistically be achieved: we use legacy systems at work that have almost 30 years of feature development, bug fixing and iterative development that run the core of our product. It runs on Motorola 68000 processors. Discontinued 68000 processors. One solution was to write new software. The ideal solution was to write new software based on modern technology and standards. The realistic solution in terms of cost to us and our customers was to build an emulator; floating strong legacy software on Linux.
The cost in resources to fully develop a robust system, with analysis, development and testing to meet the expectations of our customer base would have simply been astronomical.
This isn't a principle that applies only to software development or the corporate world. It applies when you're thinking of buying a car. What do you really need, and then what is available inside the scope of your budget?
What computer do you need for the tasks you want to perform, should it be portable or do you require the power of a bleeding edge desktop rig?
Figuring out what you absolutely require is then the basis on which to define what is possible, and perhaps more importantly in some cases what you want. You might need to consider what you need now against what you're likely to need in the future: does the new house you like have enough bedrooms for your family plans? The key is, that it's all far easier to figure out with a good understanding of the minimum, or least 'amount' of solution to achieve your goal.