- Differentiating Between Goals and Solutions
- Divergent, Critical, and Convergent Thinking in a Nutshell
- Focusing on Goals in Software Design
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Divergent, Critical, and Convergent Thinking in a Nutshell
As Figure 1 shows, three levels of thinking actually take place in every software project. The project begins with a task that you must perform. You use divergent thinking to determine goals, and solutions for each of the goals. At this point, critical thinking comes naturally because you have too many solutions, and it’s obvious that some of them won’t work. Finally, you rely on convergent thinking to convert the final solutions to a usable application. It appears quite simple in Figure 1, but in reality, most developers start with the convergent thinking and miss the other two phases.
)
Figure 1 Most software projects require that you employ three kinds of thinking.
Avoiding the trap of heading directly to convergent thinking is easier once you begin to define the task fully. Considering the task you need to accomplish leads naturally into thinking about the goals you need to achieve. The difficult part is keeping goals separate from solutions. Most developers today are programmed by marketing efforts to think of solutions, not goals. A solution is fine once you know what goal you’re trying to achieve, but the shotgun approach used by many organizations to try any and every solution without considering a goal leads to frustration for most developers.
To give you an idea of how difficult it is to keep goals and solutions separate, I’ll relate a conversation with a friend. I was discussing the concept of divergent thinking and my friend came up with the following goal: "Develop a feedback form for our book-selling web site to handle user complaints." However, this is actually an example of a solution—the kind of thinking that leads to problems in software design. It’s too specific. An example of a goal in this case would be to handle customer feedback. The task might be to make the web site user-friendly.
Design by solution is the kind of thing that happens in a meeting. You go to the meeting to discuss ideas on making the company web site user-friendly. Someone comes up a solution for the problem: Create a form for user complaints. The rest of the meeting focuses on that one solution, developers write code for it, and that’s end of the story.
But is that really the end of the story? Is the web site really friendlier because someone has created a feedback form that may or may not meet the company’s needs? Asking these questions is important. A goal will address (in a non-specific way) the requirement to make the web site user-friendly. You can see how limited this solution is by exploring other goals:
- Provide an online chat feature with product support.
- Let the user configure the web site to meet specific needs.
- Create links to third-party resources.
- Include links to related newsgroups, weblogs, and other forms of discussion.
Let’s extend this design-by-solution scenario a bit. The developer tasked with creating the feedback form is stressed to the point of breaking, so she doesn’t even write the code from scratch. Instead, she finds some code for a form on a web site somewhere for another company that isn’t even in the same business. After she changes a few lines of text, the complaint form appears online, but the user doesn’t even find blanks on it that make sense because this form is for some other company.
If you doubt that this scenario is real-world, consider your own experience. Have you gone to a web site, discovered something that was missing or that you wanted to know more about, and decided to fill out one of those customer support forms? How often does the support form actually match the company requesting the information? How often have you looked at one of the entries on the form and wondered why you had to provide that particular piece of information? As you answer these questions, the need to avoid design-by-solution becomes apparent and the benefits of relying on divergent thinking become equally evident. When you consider all the facts, the form doesn’t perform the required task properly; it doesn’t meet the intended goals. In fact, someone who didn’t have any goals at the outset probably stuck it up on the web site. There was no divergent thinking; the developer went right to the convergent part of the process because that’s where the supposed payoff lies.