This experience report was originally shared at the Carnegie Mellon University Master of Software Engineer Alumni Gathering 2010.
Introduction #
The affordances of the environment are what it offers the animal, what it provides or furnishes, either for good or ill.James Gibson, The Theory of Affordances
Ecological psychologists use the theory of affordances to help predict how animals will behave in the context of an environment. Artifact designers borrowed the idea to help make objects that are more readily usable by people. Software designers, in turn, built on what artifact designers discovered and applied similar ideas to user interface design. As software engineers, one of our main charges is designing processes fit for a particular purpose within the context of a particular environment. We need process to help us build working software. Process, like any designed artifact, relies on affordances for influencing how software engineers behave on a project. Thinking about a process’s affordances can help us better understand how software development processes work, and show us what to change so teams can improve.
The Theory of Affordances and Software Process #
An affordance is a perceivable element, such as an object or idea, which directs an animal’s thinking toward a specific set of actions. [1] Sometimes an affordance is a real thing in the physical world while other times an affordance might exist as an idea or perception. From a purely ecological perspective, affordances in an environment create niches that place selection pressure on animals enabling evolution. As such, some affordances create advantages for animals while other affordances create disadvantages. [2]
In The Design of Everyday Things, Donald Norman extended the theory of affordances and proposed using affordances to better understand how to design objects. By considering the physical attributes of an object, the purpose of the object, and the context in which the object is used, as well as the abilities, background, goals, and culture of the user, designers can create objects that are easier and more intuitive to use [3]. Conversely, undesirable behavior can be discouraged by making objects more difficult to use. The idea that people can be “nudged” into taking certain actions by both the environment and the objects with which they interact has been exploited by object designers and entrepreneurs with great effect.
As an example, consider an oversized, comfortable chair. For an American, the comfort of a chair in a living room creates an affordance which encourages you to sit and relax. But what happens if we change the context? What if our oversized, comfortable chair were placed in the dining room of a fast food restaurant? In this scenario, a chair which encourages patrons to remain in the dining room encourages patrons to linger and may prevent new patrons from being served. In this environment, an oversized, comfortable chair is inappropriate and indeed, many fast food restaurants use uncomfortable chairs specifically to encourage diners to eat faster and leave, making room for more diners. Likewise, an oversized, comfortable chair would seem out of place in a traditional Japanese sitting room in which space is limited and everyone else is sitting on the floor.
The theory of affordances applies equally to other designed things included processes. Software development processes in particular rely on affordances to encourage or discourage team behaviors. Steps in a process, even though they do not exist as physical objects, directly influence a team's behavior.
Since a software process is part of a team’s environment, a team will react differently to a process that takes into account team members’ backgrounds, experiences, and abilities. As software processes exist solely in our minds, the influence a process has over a team will vary based on the team’s perception and understanding of that process. How well a team understands their process will determine the extent to which a process’s affordances influence the team. If a process is misunderstood and the team executes it poorly, affordances designed into the process may not have the desired effect.
Affordance-Driven Process Improvement #
Studying the affordances of a software process presents interesting opportunities for team improvement efforts. The basic idea is to identify existing process affordances that are hurting or helping the team, and replace poor or harmful affordances with better ones. Of course, when something is designed well, it's challenging to notice the affordances and how those affordances positively affect behavior. For this approach to work, it's necessary to examine a process with a designer's mindset.
Affordance-Driven Design is a design methodology that shifts the focus from an artifact’s functions to the affordances which influence users to achieve a function [4]. By thinking about affordances in this way, they begin to look eerily similar to design choices affecting quality attributes from software architecture. An artifact’s affordance might promote or inhibit specific functions in the context of an environment when performing a specific function.
Thinking about process design in the same light as software design makes identifying affordances through reverse engineering a navigable task for software engineers. Rather than focusing on techniques and tools from ecological psychology or object design, we can reuse techniques already in our software engineering tool box, such as the quality attributes scenario [5]. Quality attributes scenarios describe how well a software system operates in the context of an environment while performing specific functions. Similar to software design, one way to identify and evaluate process affordances is to describe functional requirements for the process and the qualities the process should promote or inhibit as scenarios.
The generic method for Affordance-Driven Design has three steps. The result of this generic method is a list of affordances to be designed into an artifact [6]. We can apply principles learned from software architecture during the first two steps. The final step in the generic method is a simple prioritization using whichever technique your team desires.
- Identify a user’s needs in terms of functions.
- Identify affordances which may help achieve the functions
- Choose the affordances to design into the artifact which are most likely to help users achieve the function.
As an example, in one experiment focusing on affordances, subjects were asked to mix a cold drink using a blender [6]. The point of the experiment was to evaluate the affordances of the blender used by the subject how the affordances influenced the person’s use of the blender. The functions in this case were relatively simple, for example, preparing the blender, powering the blender, blending, and cleaning. The person’s ultimate goal was to create a mixed drink. When analyzing the blender and how the person interacted with the device, designers considered several functional affordances, or what software engineers will quickly identify as quality attributes. These included “countertop-ability,” “transportability,” “clean-ability,” and “mix-ability,” among others.
In this experiment, all subjects were able to complete the task but blenders performed differently relative to the identified quality attributes. Some blenders had affordances that promoted cleaning while others inhibited cleaning. Just like in software design, there were often trade-offs between qualities.
Extending this idea to software processes is relatively straightforward. All software processes have the same basic function, to develop software, but different processes value different qualities. For example, Extreme Programming values “changeability,” the ability to adapt a project quickly, while other processes might value “software requirements stability.” “Plan-ability,” the ability to see a certain distance into the future, might be more important in some scenarios than others. Once the quality attributes are known and quality attribute scenarios identified, finding the affordances in a process is usually simple.
Case Studies #
The remainder of this paper will discuss examples of process affordances taken from my experience. I define a good affordance as any affordance that actively promotes desired behavior or inhibits undesirable behavior. Conversely, an affordance that actively inhibits desired behavior or promotes undesirable behavior is a bad affordance. A poor affordance is one that passively promotes or inhibits behaviors, resulting in inconsistent and unpredictable behavior.
Affordances must be evaluated in terms of the environmental context, background, goals, and users' abilities. A child-safety locking lid on a drug container might be a good affordance for a family with children (preventing accidental poisoning), a bad affordance for an elderly person with arthritis (unable to open the container to take needed medicine), or a poor affordance for a gorilla (who opens containers by smashing them with a rock regardless of the lid design).
Square Root: Changeability Affordances #
Square Root was a five person team working on a studio project in the Carnegie Mellon University Master of Software Engineering (MSE) program [7]. Over the course of 16 months, the team developed and delivered a commercial-grade, web-based tool used by the Software Engineering Institute for research and education. The tool supported business customers following the Security Quality Requirements Engineering (SQUARE) methodology. [8] [9] About five months into the project, during the Spring semester, the team was began missing delivery milestones. Teammates were confused about tasking. Work had stalled in a variety of areas.
The team’s planning process was simple. At the beginning of a phase teammates reviewed all activities and artifacts to be completed by the end of that phase. For each identified milestone, the team specified entry criteria, tasks, how the work would be validated, and exit criteria. Milestones were estimated with planning poker. Each milestone was assigned to a member of the team. The “milestone owner” was responsible for ensuring the milestone was completed by either delegating tasks or working on it themselves.
As the phase progressed, the team learned more about their goals and it soon became clear that the plan needed to changed. When the team leader suggested changing the plan, he encountered resistance from teammates. Changeability was valued in the team’s planning process, but there were several affordances preventing change from happening.
First, the team's planning process encouraged them to commit to more work than time allowed. There was a missing connection between day-to-day progress and the overall plan, which made it easy to over commit. Second, though the team leader believed there was consensus among the team regarding the need for change, in reality teammates did disagreed with the evolving priorities. The team's planning process has poor affordances for communication and consensus building. The process neither encouraged consensus nor discouraged hidden conflict.
Third, leftover work was not addressed during planning. Over time, unfinished tasks might simply expire while others may need to change priority. This bad affordance created a sense of urgency in teammates who carried over work from a previous phase and encouraged them to resist change. Finally, assigning milestone owners had unanticipated side effects. The idea was to ensure someone was responsible for each team's goal. This worked so effectively that milestone owners exhausted themselves attempting to finish milestones. Changes to a milestone they owned were perceived as failure. Milestone owners resisted any changes that would prevented them from finishing what they promised.
Once these bad and poor affordances were identified, the team could replace them with good affordances that better promoted the changeability of their plans. The team abolished milestone ownership, created a task backlog, used task velocity from previous phases to limit the amount of committed work, and planned phases as a group rather than asking individuals to plan alone.
Black Knight Technology: Turnaround-ability Affordances #
I was once a member of a 12 person analysis and testing team responsible for evaluating a real-time track manager for the US Navy. Throughout development, software updates for the track manager were released every six weeks. Analysis had to be completed quickly to ensure the development group received feedback in time to influence the next software release. To complicate matters we were the only beta-test group which regularly performed real-time, asynchronous tests. A side effect of this sort of testing, compared to flat file testing, was that test data varied from test run to run depending on a multitude of unpredictable variables, from the time of day, to where a sensor simulator was pointing during a test run, to traffic on the test lab network. Multiple runs had to be performed and all the data analyzed to reach statistically meaningful conclusions. All identified anomalies required root cause analysis.
The test bed consisted of two separate networks, one for analysis and the other for testing. The networks were connected by a single, shared server used to transfer data. The physical environment mirrored the virtual one, with computers from each network running in separate rooms, joined by a single open doorway. The networks were disconnected in an attempt to isolate networking variables while running tests. Because of this environmental constraint, copying data (upwards of 4 GB at a time) from the test network to the analysis network took considerable time. It was not uncommon for a test run to result in bad data due to a subsystem crashing. Since analysis was conducted exclusively on the analysis network, bad data would be discovered until hours later. When this happened, it resulted in wasted effort reconfiguring equipment for test runs which could have been run immediately had the testers known.
The turnaround-ability of the team’s testing process was highly valued. In this case, there are several affordances which inhibit turnaround-ability. Testers do not have sufficient computing power to quickly examine test data prior to transferring it to the analysis network. Configuring test equipment is difficult and error prone. Existing analysis tools are geared toward root cause analysis and not intended for peeking at data. There was also a general attitude that “testers do the testing while analysts do the analysis.”
Several affordances were altered to improve the turnaround-ability of the team’s testing process. First we rearranged the physical environment, bringing two machines suitable for analysis onto the test network. Second, new analysis tools were commissioned capable of performing quick looks into the data. Third, traditional team roles were eliminated – analysts were given training on how to use the testing equipment while testers were taught how to do analysis. The result was a more cohesive team that was capable of performing more testing work with less time.
Conclusion #
When a process is not working for a team, it can be difficult to figure out what needs to change. Focusing on the process’s affordances is one technique for quickly identifying problem areas and shedding light on the qualities the team values. Affordances are subtle, usually by design. By applying lessons from other design disciplines, such as UX and software architecture, it’s easier for software engineers to apply the theory of affordances.
In each of the two cases, affordances nudged the teams to behave in ways that were contrary to their goals. Understanding the goals, and the qualities the team valued in meeting those goals, was the key to finding the problematic affordances and hinting at new affordances to use.
Modern software processes are highly designed artifacts. Though thinking about affordances is not something generally applied to process, most process designers consider heavily how the techniques and activities in a process will influence a team. Before tailoring a process, taking time to understand the designer’s intentions will help determine whether it’s the affordance causing problems or the team’s execution of the process.
References #
J. J. Gibson, The Ecological Approach to Visual Perception. Psychology Press, 1986.
A. Chemero, "An Outline of a Theory of Affordances," Ecological Psychology, vol. 15, no. 2, pp. 181-195, 2003.
D. Norman, The Design of Everyday Things. New York: Currency Doubleday, 1988.
J. R. A. Maier and G. M. Fadel, "Affordance-Based Design: Status and Promise," Maier Design Works, 2006.
L. Bass, P. Clements, and R. Kazman, Software Architecture in Practice. Addison-Wesley Professional, 2003.
A. B. Galvao and K. Sato, "Affordances in Product Architecture: Linking Technical Functions and Users' Tasks," in Proceedings of ASME Design Theory and Methodology Conference, Long Beach, CA, 2005.
D. Garlan, D. P. Gluch, and J. E. Tomayko, "Agents of Change: Educating Software Engineering Leaders," IEEE Computer, vol. 30, no. 11, pp. 59-65, Nov. 1997.
N. R. Mead, E. D. Hough, and T. R. Stehney II, "Security Quality Requirements Engineering (SQUARE) Methodology," Software Engineering Institute, Pittsburgh, Technical Report CMU/SEI-2005-TR-009, 2005.
(2009, Dec.) SQUARE Tool. [Online]. http://www.cert.org/sse/square-tool.html