In System A, there is no architect separate from the contractor. We are builders, simply. As builders, we have a direct feeling about construction. We feel it in our fingers, so it is down to earth. One result of this down-to-earth quality is that everything is somewhat experimental. We make experiments all the time. Sometimes we place a piece of wood this way. Another time, we may like to try it that way. Any time something new comes up in the design of a building, we are very likely to try and invent the best way of building it. This is not a great big invention. Just a simple invention, the way we might invent a way of tying a piece of string, to hold a broken toy together. It is just practical.
The concept of “problem and solution” is as meaningless, applied to the act of creation, as it is when applied to the act of procreation. To add John to Mary in a procreative process does not produce a “solution” of John’s and Mary’s combined problem; it produces George or Susan, who (in addition to being a complicating factor in the life of his or her parents) possesses an independent personality with an entirely new set of problems.
...there is no strictly mathematical or detective-story sense in which it can be said that the works of a poet are the “solution” of the age in which he lived...The artist does not see life as a problem to be solved, but as a medium for creation.
You can't look a big problem too directly in the eye. You have to approach it somewhat obliquely. But you have to adjust the angle just right: you have to be facing the big problem directly enough that you catch some of the excitement radiating from it, but not so much that it paralyzes you. You can tighten the angle once you get going, just as a sailboat can sail closer to the wind once it gets underway.
Disadvantages can be viewed as "problems" and we can take an energy-expensive approach to "get rid of the problem", or we can think of everything as being a positive resources: it us up to us to work out just how we can make use of it.
"Problems" can be intractable weeds, huge boulders lying on the perfect house site, and animals eating garden and orchard produce. How can we turn these into useful components of our system? Boulders on the perfect house site, for example, can be incorporated into the house itself, for beauty and as a heat storage system.
Dr. Weaver lists three stages of development in the history of scientific thought: (1) ability to deal with problems of simplicity; (2) ability to deal with problems of disorganized complexity; and (3) ability to deal with problems of organized complexity.
The history of modern thought about cities is unfortunately very different from the history of modern thought about the life sciences. The theorists of conventional modern city planning have consistently mistaken cities as problems of simplicity and of disorganized complexity, and have tried to analyze and treat them thus.
The lesson of the airplane is not primarily in the forms it has created, and above all we must learn to see in an airplane not a bird or a dragon-fly, but a machine for flying; the lesson of the airplane lies in the logic which governed the enunciation of the problem and which led to its successful realization. When a problem is properly stated, in our epoch, it inevitably finds its solution.
Another aspect of design thinking that was evident in the foregoing case studies is the tenacity with which designers will cling to major design ideas and themes in the face of what at times might seem insurmountable odds. Often the concept the designer has in mind can only come to fruition if a large number of apparently countervailing conditions can be surmounted.
Even when severe problems are encountered, a considerable effort is made to make the initial idea work, rather than to stand back and adopt a fresh point of departure.
The problems themselves, though they once obsessed you, and kept you working late night after night, and made you talk in your sleep, turn out to have been hollow: two weeks after your last day they already have contracted into inert pellets one-fiftieth of their former size; you find yourself unable to recreate the sense of what was really at stake, for it seems to have been the Hungarian 5/2 rhythm of the lived workweek alone that kept each fascinating crisis inflated to its full interdepartmental complexity.
When you sign the contract for the construction project, you are agreeing to make a Thing—app, website, whatever. And you will have agreed to deliver this Thing on a certain date, also known as a deadline. From this point forward, the goals of shipping the Thing on time and actually solving the client’s problem will be in competition with each other.
Richard Feynman was fond of giving the following advice on how to be a genius: You have to keep a dozen of your favorite problems constantly present in your mind, although by and large they will lay in a dormant state. Every time you hear or read a new trick or a new result, test it against each of your twelve problems to see whether it helps. Every once in a while there will be a hit, and people will say: ‘How did he do it? He must be a genius!’
A true revelation, it seems to me, will emerge only from stubborn concentration on a solitary problem. I am not in league with inventors or adventurous, nor with travelers to exotic destinations. The surest - also the quickest - way to awake the sense of wonder in ourselves is to look intently, undeterred, at a single object. Suddenly, miraculously, it will reveal itself as something we have never seen before.
Motorola developed what it called a 'technology shelf', created by a small group of engineers, on which were placed possible technical solutions that other teams might use in the future; rather than trying to solve the problem outright, it developed tools whose immediate value was not clear.
The identification a good craftsman produces is selective, that of finding the most forgiving element in a difficult situation. Often this element is smaller, and so seems less important, than the larger challenge. It is an error in technical as in artistic work to deal first with the big difficulties and then clean up the details; good work often proceeds in just the opposite fashion.
Each pattern is a rule which describes what you have to do to generate the entity which it defines. It is a three-part rule, which expresses a relation between a certain context, a problem, and a solution.
There is an imperative aspect to the pattern. The pattern solves a problem. It is not merely “a” pattern, which one might or might not use on a hillside. It is a desirable pattern; and for a person who wants to farm a hillside, and prevent it from erosion, he must create this pattern, in order to maintain a stable and healthy world. In this sense, the pattern not only tells him how to create the pattern of terracing, if he wants to; it also tells him that it is essential for him to do so, in certain particular contexts, and that he must create this pattern there.
It is in this sense that the system of patterns forms a language.
The success and spread of a particular tool – and this tool can be organizational or administrative as well as mechanical – has another consequence. Any task tends to be structured by the available tools. It can appear that the available tools represent the best or even the only way to deal with a situation.
Thus is may be wise, when communities are faced with new technological solutions to existing problems, to ask what these techniques may prevent and not only to check what the techniques promise to do.
Framing is all about the problem and the business value. It's the work we do to challenge a problem, to narrow it down, and to find out if the business has interest and urgency to solve it.
The framing session is where a feature request or complaint gets evaluated to judge what it really means, who's really affected, and whether now is the time to try and shape a solution.
I have a running joke that one of the most useful things I do when coaching or consulting is to say to people “Yes, that does sound like a problem. Have you tried solving it?”
Part of why this is a joke is that actually most of the useful work happens prior to the point - the hard part is actually articulating what is going wrong well enough that it seems like a soluble problem - but there is genuinely something useful about this, because often it feels people are looking for permission.
Without the external prompt, solving their problem is not something they noticed that they were allowed to do.
I think part of the difficulty in allowing ourselves to properly delight in the imperfect, comes from conflating delighting in something with wanting it to happen. This isn’t the case. You can appreciate something as it exists while acknowledging its problems. You can see that a fire is beautiful without becoming a pyromaniac, and you can appreciate the absurdity of your political situation without thinking it’s good.
Even if a delight in the imperfect causes you to want more imperfection in your life (and it should), there is no shortage of imperfection to seek out. The imperfect is not scarce, it’s abundant. If you find imperfection delightful, you will never be short of things that delight you, even if you fix any given problem. Solving problems and smoothing out imperfections doesn’t remove the source of delight, it merely opens up new vistas for it. You could give yourself over totally to delight in the imperfect and never run out of things to explore, even without creating your own.
Too many product managers and product designers want to spend all their time in problem discovery, and not get their hands dirty in solution discovery – the whole nonsense of “product managers are responsible for the what and not the how.”
Suppose you have a problem to solve. What do you do?
Well, you sit down and think real hard, and after extensive and careful planning you try the well thought out and rigorous solution that you have thought up. Right?
No, wrong! Bad.
The correct thing to do when you have a problem is:
Think for a short amount of time.
Make sure it is safe to try things.
Try something you think will work.
Observe the result. If you succeeded, yay you solved the problem! If it didn't work, think about what that means for the nature of the problem and try again.
…one of the simplest of diseases managed to utterly confound us for so long, at the cost of millions of lives, even after we had stumbled across an unequivocal cure. It makes you wonder how many incurable ailments of the modern world—depression, autism, hypertension, obesity—will turn out to have equally simple solutions, once we are able to see them in the correct light. What will we be slapping our foreheads about sixty years from now, wondering how we missed something so obvious?
There are two classes of problems caused by new technology. Class 1 problems are due to it not working perfectly. Class 2 problems are due to it working perfectly.
...Class 1 problems arise early and they are easy to imagine. Usually market forces will solve them. You could say, most Class 1 problems are solved along the way as they rush to become Class 2 problems. Class 2 problems are much harder to solve because they require more than just the invisible hand of the market to overcome them.
...Class 1 problems are caused by technology that is not perfect, and are solved by the marketplace. Class 2 problems are caused by technology that is perfect, and must be solved by extra-market forces such as cultural norms, regulation, and social imagination.
How would you change this structure so that you could put a masonry brick on top of it without crushing the figurine, bearing in mind that each block added costs 10 cents? If you are like most participants in a study reported by Adams et al. in Nature, you would add pillars to better support the roof. But a simpler (and cheaper) solution would be to remove the existing pillar, and let the roof simply rest on the base.
A series of problem-solving experiments reveal that people are more likely to consider solutions that add features than solutions that remove them, even when removing features is more efficient.
“Do not propose solutions until the problem has been discussed as thoroughly as possible without suggesting any.
I have often used this edict with groups I have led—particularly when they face a very tough problem, which is when group members are most apt to propose solutions immediately.”