Divergent Versus Convergent Thinking: Which Is Better for Software Design?
- 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
Not many people consider the thought process that goes into the development of good software. It’s important, though, to consider the thought process if you ever want to create software that achieves a given task and develop that software within the specified timeframe, on time, and within budget. Many consultants are in business today because they’ve achieved something that in-house developers lack: the ability to think divergently. Let’s distinguish between the two types of thinking:
- Divergent thinking is the process of creating a list of items based on a single input. In this case, you begin with a task and consider all the ways that you can accomplish that task without thinking in specifics.
- Convergent thinking is the process of converting all of the general ideas—the goals and non-specific solutions—into the specific solutions that form an application.
Let me say up front that there’s no payoff in divergent thinking, and it often appears to take you further away from your goal, rather than helping you achieve it. Divergent thinking isn’t glamorous, and many people consider it a waste of time and effort. Yet, without divergent thinking, in many cases you can’t reach the payoff of convergent thinking, because you haven’t fully considered the problem you’re trying to address. In short, divergent thinking is a necessary part of software design, which many companies avoid today—to their detriment.
The basic way to look at this process is that you diverge from the task to explore all possible ways to accomplish it and then, after careful consideration, converge in a set of solutions that yield the finished application.
By now, I can hear many of you saying that, as a developer, you don’t have any control over design decisions. When the project reaches you, someone else has already defined the design specifications. But divergent thinking can occur at many levels of the design process, even the part that you’re responsible for accomplishing. Every specification is a task that you must accomplish. Divergent thinking begins with a task and moves on through the phases described in this article. Any task, no matter how big or small, can benefit from divergent thinking.
Differentiating Between Goals and Solutions
The onslaught of marketing emphasizing solutions, rather than goals, is infecting the entire developer community. But a solution is only valuable when it achieves specific goals.
Often, developers don’t really know the goal of a particular piece of software. In fact, the problem begins with a poor definition of the task that the software must perform. Consider the task of paying an employee. (After all, if you want the employee to perform useful work, you must provide payment.) A list of goals for the task of paying an employee might include the following:
- Obtain the employee’s information.
- Track the employee’s work hours.
- Discover any special payment conditions.
- Calculate the amount of pay for a given timeframe.
- Record the payment amount.
- Pay the employee.
These goals define how to achieve the task, but they don’t tell how to perform the task. A goal doesn’t provide implementation; it merely defines what must take place in order to achieve the task.
Because a goal doesn’t define how to perform the task, many developers skip this step and go right to the solution. However, because there’s no goal, the solution the developer tries might not even work. It may not be the right solution and most likely isn’t the most efficient solution for a particular business. In many cases, the solution is one that someone has used successfully in another business after pounding it into shape—a process akin to fitting a square peg into a round hole. By defining goals first, you can diverge further from the task in your thinking process, to define several possible solutions for each goal. For example, consider the second goal in the list above, "Track the employee’s work hours." You could try any of these solutions:
- Ask the employee to fill out a timecard.
- Use a time clock with which the employee punches in and out.
- Require the supervisor to take role call.
- Track employee activity and record time based on that activity.
- Record the employee’s entrance and exit from the office.
- Designate a third party to track employee time.
- Track employee hours based on output.
Each of these solutions fulfills the goal of tracking employee work hours for a particular kind of business, but not every business can use every solution. In addition, businesses that can use multiple solutions will likely find that one solution works far better than any of the other solutions for their particular needs. For example, a business that tracks employees’ time based on their work for a particular account might rely on a timecard that tracks the account as well as the time worked. A business of this type can’t use a time clock. And, unless you want to drive the supervisor crazy, you also won’t task him or her with this responsibility. However, if the employee is working at a computer all day, you might be able to track the employee’s time based on computer activity. Working on specific files will trigger tracking for the associated account. In short, even though a timecard would work, using the computer to track activity automatically works better.
All of this pre-design activity requires divergent thinking. Your thought process is diverging from the original task, which after all is to pay the employee. At this point, you have many solutions, most of which won’t work. Many developers would say that things have become too complex at this point, and simply consider the time wasted. However, by employing critical thinking, you can move into the convergent thinking portion of the design process at this point. By defining how well each solution will (or won’t) work, you can eliminate many of those possible solutions. You know what won’t work, based on this phase of the planning process. Without divergent thinking, you wouldn’t have this information. In addition, once you decide on the one solution that you want to design into the application, you may still have other solutions that you can use as backup, in case the first solutions fails to work as anticipated. Consequently, you’ve saved yourself a considerable amount of time and effort in the future, even though there isn’t any payoff today.