In a recent post on how slack can improve productivity I alluded to the psychological effect of task driven development. I want to explore this point further.

First, let me define task driven development simply as the process of developing from a task list. A developer is assigned a set of tasks. When all the tasks are complete, development is complete.

To begin exploring the psychological effect of task driven development, I want to parallel it with gaming. People enjoy games. Given a set of rules within a system, we work to figure out a solution.

The process of tasking creates a game. The system is a set of tasks and the rule is to complete the tasks. So how do we best play the game?

Focus on completing your tasks.

Now on the surface that might sound good. In reality this is not good. By gaming another psychological effect is introduced, tunnel vision.

Let's look at tasks as instructions. For this example the goal is to start a car. Consider the following set of instructions:

• Get the keys off the key rack
• Unlock the driver car door
• Put your foot on the brake
• Put the keys in the ignition
• Turn the keys until the car starts

While these instructions would likely help most people start a car, instructions create a slippery slope.

How granular do the instructions need to be? In the example, do we need to describe the keys or the brake? The impetus is on the instructor. They must have the knowledge and discretion to properly create each instruction necessary to reach the goal. This slides us farther down the slope.

Following instructions can be debilitating. Such instruction removes the need for you to think. In doing so, you lose a critical component of problem-solving. Going back to our example, what happens if the keys aren't on the key rack? What if the car has push button ignition? The instruction is now incorrect and you do not know how to proceed.

Knowledge workers, such as software engineers, posses a craft. A craft that requires an element of creativity. We can not recreate their work simply by completing a set of tasks. In the case of software engineering, the result would likely not work or come with technical debt.

To avoid the psychological effects of task driven development, we can transition to feature driven development. Tasks that focus on simple, functional units. Going back to our example consider the simple instruction:

• start the car using the car keys

While this is seemingly less helpful, it leaves room for change (slack). It provides enough context to complete the task, but allows creativity in finding the keys and determining how to use them to start the car.

Find this interesting? Let's continue the conversation on Twitter.