Request for feedback: The Soft Side of Software Engineering

Greetings, software developers. We have a request today: would you be willing to give us feedback on a chapter John Fox is working on (for a book titled The Soft Side of Software Engineering)? We’ll include the chapter here, as well as a link to a Word version of the chapter (in case you’d like to comment within the chapter itself). We’d like your thoughts about the usefulness of the chapter to you, about how to increase its usefulness, and/or about what you’d expect to see in a book about the soft skills required in the field of software development.

You can access the Word doc here.

Give us your feedback by commenting on this blog post or by sending your thoughts (or the marked-up Word doc) via email to jfox [at] and devonm [at]

We thank you!

Chapter 4: Rewards, Goals, and Inhibitors [DRAFT]

Why programmers program

My core theory on this fascinating topic is that programmers and many other people, especially men for reasons soon to be discussed, like to engage in activities with variable reward mechanisms. Hunting, fishing, golf, and gambling all are common everyday examples of activities with variable rewards and I’m sure you can imagine some others. That is, you never know when that big fish will bite or even if it will actually bite at all. But this is exactly what makes it exciting to participate in these events in the first place. If you knew that you’d catch a trophy fish on every cast, then what’s really the point? If you birdied every hole in golf it wouldn’t be much of a challenge and it would soon lose its grasp on you.

So let’s take a quick review of the scientific research that supports this theory of variable rewards for programmers. There are four basic types of reward schedules defined by psychologists (mainly behavioral psychologists); fixed and variable ratio and fixed and variable interval. The key is that one set is based upon activity (the ratio ones) and the other is based upon time (the interval ones).

Fixed & Variable Rewards

Fixed-ratio schedules would be where the subject receives a reward every nth time he performed a specific activity. The value of n could range from one to almost any number within reason. If you caught a fish every fifth cast for example, this would be a fixed-ratio reward. More likely however, it might involve some piecemeal rate compensation in a factory where a worker receives so much compensation for every five widgets assembled or whatever the case might be.This is a strong motivator of human behavior for as long as the individual can hold out and this reward mechanism is used quite frequently in work settings where good data can be easily tracked, such as manufacturing.

A variable-ratio schedule is where rewards come periodically with no exact pattern to them, although they usually have some typical average. Nabbing birdies (a birdie is one stroke under par for a particular golf hole) on holes 5, 11, and 14 (out of 18 holes for you non-golfers) would be a variable ratio reward. You would not know what holes you might make birdie on, but you may know that on a typical day on a typical golf course you notch around three birdies. Variable-ratio reward systems can lead to exceptionally high rates of response and usually keep people interested over the long term in the associated activity.

Fixed-interval rewards are those where rewards occur in a certain period of time. If you caught a fish every 15 minutes for example. This reward scheme generates low interest, especially just after the reward has occurred. Think about your annual bonus.

Variable-interval rewards are more exciting because one never knows exactly when a reward will happen, but they must know within some range. For example, you probably wouldn’t have many people fishing if you went eight hours between catching fish (unless perhaps you’re fishing for very large game fish, such as Marlin – variable rewards are relative to the activity). At some point people will lose interest in unrewarded activities and of course this will vary based upon the particular circumstances and the person involved. Variable-interval rewards can be very addicting and will keep people highly engaged in activities, in some cases for a lifetime. The gaming industry knows well the lessons of variable rewards and how much it can take control of one’s focus, especially in certain vulnerable individuals.

One of the key areas of the human brain called the Ventral Tegmental Area (VTA), located in the mid brain, is responsible for manufacturing dopamine, which as you’ll recall is a complex functioning hormone released when people feel good. It’s a feeling that people intensely cherish and the VTA region of the brain has been found to be more active in men. What better way to elicit a quick dose of dopamine than to find out that one of your code snippets works just as you expected? Whether or not this means that men are more likely to release dopamine as a result of incremental programming achievements is not yet clear, but it’s potentially another indicator to explain why men are somewhat more attracted to careers in programming than women.

Delayed/Instant Gratification

One more related topic here before we continue. When you combine variable rewards with relatively quick gratification (perhaps not instant) you have a formula for strongly addictive or sought out behavior. So while a programmer is entranced in their daily work they receive periodic “rewards” whenever their unit tests or even partial unit tests succeed. When they are working on a complex algorithm they can obtain variable rewards even when very small code portions begin to function properly.

These small fragmented rewards can be played out rather quickly, depending upon the type of programming being done. On your typical web app development project, you can quickly fire up a browser pointing to your development environment and promptly see if your code in question works properly or not. This type of scenario can literally play out hundreds of times within a single day. This is why developers sometimes lose complete track of time and are not punctual for meetings (or at least you hope that’s why they’re late). I firmly believe that this is a major reason why many people choose a career in programming. It’s difficult for me to think of too many other professions that have a combination of both variable rewards and quick gratification, although I’m sure there are several, especially in light manufacturing jobs.

In many job functions the results of your work will not be known for months or even several years. Once you become accustomed to this near instant gratification, having to wait months to see real-world results can be a rather difficult adjustment. These near instantaneous results are really many miniature rewards, accompanied by a small shot of dopamine, that occur throughout each workday. It’s no wonder that we like this type of work; our self-esteem is constantly being fed with tasty little morsels all day long. This may be another indication as to why developers would rather not spend as much time on planning and design activities. These upfront duties aren’t typically providing the frequency of rewards that programming creates and besides that, programming can be done in private with no one disrupting you, a situation many developers prefer . The variable reward portion of this equation comes from the fact that not every code change or addition will work the first time or even subsequent times for that matter. Sometimes the code works just fine and other times there are problems that may take days to remediate. Not knowing if a certain chunk of code will work for sure or not is what keeps us going and the thrill that occurs when it works just like it was designed to work can be particularly addicting. I’ve known developers who have labored on for 20 hours and even longer, without significant rest breaks, in order to track down and solve a problem or fix a logic error. There were probably mini breakthroughs, or rewards, here and there that kept them going until they finished.

Studies on gratification teach us that men are less prone to delay their gratification than women, at least in the U.S. (Funder, pg 190). That is, in general, males prefer not to wait as long for their rewards. This, if even remotely true, may at least partially explain why there appears to be substantially more male programmers than female programmers in the United States. Refer to the Chapter on Gender for more a detailed breakdown of women in software engineering. My own experience reflects approximately the same results. I have worked with a limited number of female programmers over the years and even fewer female hardware engineers and network administrators. We will explore this topic from a different perspective when we discuss social norms and influence.

Why people do and don’t work, aka Motivation


As it so happens, I was an interested spectator on a great lesson in human motivation several years ago while working for a light manufacturing company. The company decided to launch a program to provide recognition to certain high performers in the warehouse, in the hopes that everyone’s performance would improve and therefore the company as a whole. The way the program was conceived was that every month some hardworking and deserving employee would be designated as the “Employee of the Month” (there’s actually a movie with this title that plays out similarly). Their name would be printed in an extremely large font on a huge banner hung high in a frequented part of the warehouse. In addition, their name would be added to a running banner of all the month’s winners over the years. If I recall correctly, there was a nominal bonus distributed to the lucky employee as well.

However, after a few months, some unintentional and unwanted behavior began to emerge. Employees who were not selected as monthly winners became jealous and offended. At first it was somewhat civil, but several months into the program certain employees were now becoming quite vocal and agitated about how they had been snubbed and that they had certainly performed better than so and so and was therefore much more deserving of that month’s acknowledgement. Soon after the casual grumbling it became such a mess that it was now down right de-motivating for many employees. The thinking went along the lines of this; “well if they don’t think I’m better than Jim, I’ll never get that award, so I might just as well give up right now”. As you may have already surmised, the program was soon cancelled and I do not recall another taking its place.

This concept will be elaborated upon later in this section; however the key point is that the warehouse workers had become focused on the wrong goal. The goal was also an external item and the motivation to work hard did not come from within the person, but rather as a response to the reward program. This is a common theme for motivation within the workplace and there will be much more discussion in this vein forthcoming. The warehouse motivational program just discussed is quite common throughout the American workforce. At first glance it appears to be logical. Reward the desired behavior and people will repeat it. Well as it turns out, this logic is actually somewhat flawed and it’s really somewhat closer to the other way around.

Behaviorist psychologists have been promoting this type of reward program for decades. It’s based upon studies with animals such as rats and pigeons. Reward them with a pellet of their favorite choice and you can reinforce many incredible types of simple behavior. The risk here is two-fold. One is that you may inadvertently reward the wrong behavior, thereby reinforcing something that either provides no value, or in some cases, make things worse. A classic experimental example is that of a lab pigeon that happens to be turning around when a pellet is randomly dispensed in his cage, which now begins spinning around at a furious pace, assuming incorrectly that the pellet was a result of the turning behavior. Of course, people are much more complex than animals and what works with a pigeon may not necessarily work with your lead developer. Let’s hope not at least.

The other more serious case is where external rewards come into play with real thinking people. A classic experiment was performed many years ago by Edward L. Deci, a noted social psychologist. This experiment, and many other supporting ones over the years since, revealed that once people were externally rewarded for doing something they naturally enjoyed; their desire for that activity would begin to diminish. The thought process is considered to be along the lines of: well I must not like it that much if I do it for money (or other comparable rewards). It was found that elementary age students who were paid to read a certain number of books would at first work harder to read the books in exchange for the money. However, follow-up studies determined that their desire for reading had now dropped below that of their pre-reward program levels. The net result was that external rewards improved short-term performance, but actually degraded long-term performance. What someone once did for just the intrinsic joy and satisfaction it garnered was no longer satisfying for them. And that’s the basic problem with reward systems, once the rewards stop; the preferred behavior may well stop too. Year-end bonuses fall into this category. Once companies start dishing them out, year after year, they become expected and they begin to lose their perceived value for the employees and hence the company.

Psychologists have a name for this scenario (of course you knew that was coming by now) where one loses interest in an activity after being paid for it. It’s called the Overjustification Effect. What was once a rewarding diversion in its own right is now considered to be work and therefore not nearly as enticing. Obviously this is an obstacle that the business world cannot do a great deal to overcome. People are not going to take up programming or project management on a full time basis just because it’s fulfilling for them. They need to earn a living, however there are other ways to help resolve this dilemma.

Deci and Ryan represented this external reward system more broadly to signify outside control of our actions. So instead of performing some activity because we inherently wanted to, we are now being controlled by an outside force in terms of said activity. This continuum of control must be balanced where the individual feels in control of where they find themselves on the range of outside influence versus self-control.

William McKnight, the visionary founder of one of Minnesota’s most famous companies, 3M, has a quote that I’ve referred to many times. I’ve actually modeled my style of management around his philosophy. Many believe that McKnight's greatest contribution was as a business philosopher, since he created a corporate culture that encouraged employee initiative and innovation.

So here is McKnight’s basic rule of management that was laid out way back in 1948:

"As our business grows, it becomes increasingly necessary to delegate responsibility and to encourage men and women to exercise their initiative. This requires considerable tolerance. Those men and women, to whom we delegate authority and responsibility, if they are good people, are going to want to do their jobs in their own way.

"Mistakes will be made. But if a person is essentially right, the mistakes he or she makes are not as serious in the long run as the mistakes management will make if it undertakes to tell those in authority exactly how they must do their jobs.

"Management that is destructively critical when mistakes are made kills initiative. And it's essential that we have many people with initiative if we are to continue to grow."

To this day 3M maintains its policy of allowing employees a percentage of time to tinker and explore new ideas. Many of their most famous inventions came as a result of this policy and they continue that tradition even in times when business ideas such as these are routinely mocked by other companies. They realize that autonomy is a key motivator and they keep control to a minimum.

Management should ideally be focused on what tasks are to be done and not define how these must be done too rigidly. This is where technical people need to exert some control of their own and management becomes a sounding board and cheerleader. Management certainly needs to guide and monitor what is going on so that business objectives are met, but exerting too much control over the “how” something gets done can be severely disabling for technical people. The exception here may be in teaching one a new technique of how to do something more efficiently, something nearly all technical people crave. However, it’s unlikely that managers are the ones who are the experts in how something technical should be implemented.

I once worked for a highly intuitive and successful manager, whose name was Bruce Clark, who was technically competent, genuine, and exceptionally engaging, a rare combination of attributes in our technical world. Bruce taught me many valuable lessons, but one I distinctly remember, was to keep customers focused on requirements and not solutions. Well now I realize why this makes so much sense. People want control of what they consider to be their domain of knowledge and expertise. Having someone tell them how to design a solution, while they may actually be correct, is not the best way to intrinsically engage a technical resource. This is especially true when it comes to working with men.

John Gray, in his now famous book Men are from Mars and Women are from Venus points out how men like to “solve” women’s problems (and men’s problems too) whereas women just want their emotions to be understood. Leading people to their own conclusions will almost always yield higher rates of job satisfaction. While this is not universally true, it is a good rule of thumb. There are certain categories of people who are more risk averse and these types of employees may well appreciate clear and distinct directions from superiors, so as not to be held too accountable when unexpected outcomes occur. So it appears that people have an innate need to be in control of their work and not have their work be in control of them, at least to a certain degree. There needs to be some challenges to keep people interested and focused, but extreme challenges on a regular basis will begin to create dangerously high levels of stress, which is described in more detail later.

The real key here becomes personal choice, but of course we can’t have everyone doing just what they please. That is why good managers and leaders focus on the “What” and let the competent people they’ve assumedly employed focus on the “How”. In software development the How can be critically important, as certain high profile incidents have clearly demonstrated.

Intrinsic Motivation & Rewards

There have been many studies in this vein beyond those conducted by Deci and Ryan just reviewed. Cameron et. al. (2001) performed a meta-analysis (see Chapter 1 for a review) on several studies on the effects that rewards may have on different types of performance. Their results are somewhat different from those of Deci and Ryan as subsequent research has reviewed the effect of additional performance parameters. These parameters include more specific instances of performance contingencies such as rewards offered for surpassing a specific score or exceeding the work of others. The results of this meta-analysis show that providing rewards for exceeding others has a positive effect on free-choice intrinsic motivation rather than a negative one, as Deci might not have predicted. Additionally, in studies of self-reported task interest, rewards offered for surpassing a specific score and exceeding others showed positive effects. Cameron’s group also found that for those tasks of high-interest, verbal rewards were found to improve both free-choice and task interest, meaning that the boss’ approval still holds some weight whether a monetary reward is involved or not.

The bottom line, at this point in time anyway, is that rewarding performance and success provides positive effects compared to rewarding for simply doing in and of itself. So it pays to be especially careful when constructing reward mechanisms.


So if we work on the assumption that a feeling of autonomy is good for development teams, then we need to consider other ramifications. Software project goals, such as feature/schedule estimates, are better defined by the group than dictated from above, at least in terms of personal commitment anyway. Development teams will strive harder to achieve the goals they set for themselves rather than those coming from the business units or upper management (however, while they may work harder to achieve their own goals, they may also set them too low – this will be discussed later). The trick comes in how this mutual goal setting is executed by both parties. Defining the broader issues facing the company will usually help the team set goals that are realistic for their development needs as well as for the company. Even though we technical people don’t always make the most astute business decisions, we do know that what is good for the goose is good for the gander. This is why walk-around-management is helpful. People can rally around the larger mission and stretch themselves to achieve what’s necessary to succeed when they understand the linkages and their personal involvement. Technical staffs need to be reminded on a regular basis about the larger corporate mission, since we have a tendency to dive deep into technical details and may easily lose sight of the broader picture and the ultimate business outcomes.

There are many other psychological impacts in regards to goals. Locke and Latham (1990) and others report that contributors who were convinced to attain specific goals performed better than those who were just asked to do their best. While people will vehemently exclaim that they cannot achieve any more when specific goals are established, because after all they are already doing their level best, the research just doesn’t support these assertions. Furthermore, when people are asked to set their own goals they inevitably set them too low. Of course with certain tasks, such as programming, setting goals may have adverse and unforeseen consequences. Coding can be done in a myriad number of ways. Just requiring that modules are completed on time is not enough. Hard coding and not handling special cases and error conditions properly may actually cause additional rework further downstream and end up being counterproductive in the long run. This is yet another reason to have experienced development managers in place and another rationale for utilizing code reviews on a more periodic basis.

Motivation in Software Engineering

Motivating a computer programmer is somewhat like motivating an eleven year old male gamer. There’s absolutely no problem getting the kid to play X-box for nearly 18 hours a day while he’s desperately trying to set his personal high score or beat another kid some six time zones away. But the trick is how do you get him to play the games you want him to play, when you want him to play them? This is the basic problem when you have an abstract and challenging activity that you’re trying to conquer. You might become so entranced in the “game” that you may then lose sight of the overall objective. Programming really does become a game of sorts for some developers and it is very easy for them to lose focus of the bigger picture. That is why developers may, in certain instances, lose complete track of time and miss appointments or that important code review that’s been scheduled for weeks. They begin tinkering with a new algorithm that uses some new technology, AJAX perhaps. Soon they’re deep in the weeds discovering all the pitfalls and advantages of AJAX. They’re off searching the web looking for code snippets, reading forum threads to find answers and suddenly they’re out of bounds on their project and conquering AJAX has now temporarily become their top priority.

Therefore, motivation of programmers, to some degree, is more a matter of focus than of actual motivation. Developers want to learn more “tricks” and find those hidden passageways so that they may have bragging rights in front of their fellow programmers. Many people in the software development profession are naturally motivated. So one way to achieve your goals and keep programmers suitably motivated is to promise them that there really will be time available for some exploring of new techniques, as long as the larger goals and schedule objectives are met. Allowing developers time to explore and experiment is a tremendous motivational technique. After all, this has worked so successfully for decades for 3M. But, here’s the best part, it probably won’t cost you any calendar time and if your programmer is a salaried employee (and you’re not paying them by the hour) it won’t cost you any more money against your budget either. That’s because time will get lost when the developer is immersed in learning a new technique and if you’re at all lucky your project may actually benefit from the learning at some future point and perhaps even on the current project. I’ve seen some extreme cases where entire breakthroughs have resulted from this approach enabling projects to achieve results that were not previously planned or predicted. The project now has taken on a whole new perspective with exciting novel possibilities that were not even an option previously. After all, this is why we’re all in the business, right?

Researchers have identified two broad types of achievement goals; performance goals and learning goals. Learning goals focus on the attainment of new skills while performance goals are focused on mastery of a particular ability. It has been discovered that learning goals may be better suited for acquiring new skills than performance goals, especially when there are set backs or negative feedback on performance goals. This research fits right in line with what many of us have suspected all along; that developers love to learn and when new tasks are framed as learning opportunities, they tend to flourish (Moskowitz & Grant, 2009).

Hawthorne Studies

Back in the 1920s, a group of researchers from the National Academy of Sciences began studying workers of the Hawthorne telephone equipment plant of Western Electric in Chicago, Illinois. Later on, researchers from Harvard Business School also worked with employees of this same plant. These studies were designed initially to understand what effects certain environmental conditions might have on worker productivity. The results surprised the researchers; this is what tends to happen in studies which ultimately become famous. It didn’t seem to matter what conditions the scientists altered. No matter what they did, productivity improved. The first study was to observe the effects of changing illumination levels on productivity. Increased lighting did indeed improve productivity. However, a short time later, when lighting levels were reduced back to their original intensity, productivity surprisingly improved again. Not all environmental changes produced increased output and the resultant effect, now known as the Hawthorne Effect, is not terribly long lasting. Increased productivity can be observed for several days or somewhat longer. These experiments initially confounded scientists of all types. Eventually the ultimate learning here was that it was the attention and feelings of importance garnered by the workers that improved the worker’s production and not the actual physical work conditions.

So what is the learning, if any, here for us? For me it means that even though we work in an industry dominated by introverted and analytical males, they still need to sustain feelings of importance and be genuinely included in all related activities. Just because some of us are typically not as social as other people, we still require and desire feedback on our work and to know how we fit into the bigger puzzle. Feeling important is one of the most significant of all human needs according to the soft skills legend Dale Carnegie. This is basically true for everyone. Never underestimate the power of inclusion and exclusion, perhaps the most powerful force known to humankind.

While it may be justified to assume that because someone does not initiate many conversations with you, that they really don’t prefer to interact with you, this is usually not the case. Introverts are thinking many thoughts; it’s just that many of them never see the verbal light of day. The Hawthorne Studies reveal that the WAM management technique featured earlier really can be effective in demonstrating to employees that you care and that by extension they are important to the organization. This is why it is also imperative to spend the most time with the most important people on your team.


Many Industrial/Organization psychologists believe that most workers really just yearn for respect. One would think that highly educated professionals would crave it even more so. My experience with developers and other related technical staff unscientifically confirms this hypothesis. Providing reasonable delivery schedules and resisting the management enticement to micromanage in excess are basic privileges that convey professional dignity and respect. Perhaps nothing de-motivates one more than lack of respect for basic worker considerations.

Organizations have what is termed a Psychological Contract with their employees. It is unwritten in form, regardless of the actual written agreement if one exists, and is typically an unspoken contract as well. This agreement basically specifies a set of expectations that workers and employers have for each other and it is unique for each employee. Generally these psychological contracts stipulate that in return for respect from the employer, the employee will be loyal to the company (Statt, 2004).

The potential problem with these unwritten psychological contracts is that they may be interpreted differently by virtually everyone. As mentioned in the Generation Gap section, younger employees, who scored higher as a group on narcissism than older employees, may expect that they are entitled to additional overall compensation and benefits. This may subsequently lead to more serious problems such as employee turnover or low morale. Managers need to be cautious in how they deal with these delicate issues and not just with Gen Y employees. It’s very easy to make off-hand remarks about potential rewards for project successes and while the manager may quickly forget these conversations, the employee will absolutely not. And I highly suspect that this holds especially true for analytical people.

Kohler Effect

The Kohler Effect, named after researcher Otto Kohler back in the 1920s, occurs when a less capable person working on conjunctive or cooperative tasks increases their efforts in the presence of more capable performers. If work partners are either too much better or about the same at the task the effect appears to be mitigated. The theory here is that workers do not want to be responsible for the poor results of the group and the other thought is that they will not care to be designated as the weaker developer or whatever the task may be. Not surprisingly, these same studies reveal that men appear to strive harder when paired with women on the same task. While these tasks were generally physical in nature there is some evidence that the Kohler effect applies to cognitive tasks as well.

The key here is to pair people together that are reasonably comparable in their skills in order to realize the benefit from this effect. Too much skill discrepancy and people may lose the motivation to keep up.


Attribution Style & Task Persistence

Attribution style refers to how one views their connection and responsibility with situational outcomes. That is, do they think that outcomes are a result of their internal capabilities and corresponding actions or is it a result of circumstances outside of their control. This may seem somewhat academic but it appears to be a factor in task persistence, something clearly vital in software engineering. The theory differentiates between ability and effort and people who believe that they succeed primarily due to their own innate ability may not perform as well as those who believe that their effort was instrumental to their success. This would suggest that managers should focus on supporting vigorous task effort rather than convincing someone they have the innate intelligence and talent to succeed. The underlying logic is that if someone fails on a task initially, they may feel that it’s outside their scope of capability and therefore why should they bother continuing with something they just aren’t capable of solving anyway. However, someone who believes that the effort that they exert has more to do with successful task completion may have an improved chance of triumph. There is a limited amount of research that supports this claim (Rozek) showing that participants with internal attribution styles do persist longer than participants with external attribution styles, at least on certain types of cognitive tasks.

My own personal experience in the domain of task persistence provides further evidence that this is the case, although it may be rare. I’ve witnessed software professionals that had somehow become convinced that they didn’t have the capability to complete their project deliverables. They thought it was hopelessly beyond their competency level and felt they had exhausted all of their options. Once software professionals cross this cognitive divide their output may plummet noticeably. Rather than begin working even harder to overcome the obstructions they may start looking for political ways out of the predicament. Asking to work on other projects or even challenging the project requirements are common outcomes.

Persistence & Goal Visibility

Research has shown that people will lose interest in completing tasks for several different reasons. One major cause is lack of goal progress visibility. If someone has no real idea of how close they are to completion of a complex task, their performance tends to diminish (Moskowitz p. 282). In development this can occur when modules are not properly divided. Modules that are too large and wieldy may be more difficult to monitor in terms of completion status. Sometimes there may be no realistic choice in the matter, but when possible smaller more compact modules will allow developers to have more of a laser focus on the efforts required for task completion. Another issue for developers is that in certain problem situations the solution is essentially and all or none proposition. In these cases you really don’t know when the breakthrough will come until suddenly, there it is right there in front of you. This represents what is frustrating but, also so rewarding about our undertaking as was highlighted earlier in the variable reward discussion.

A second reason people lose concentration on goals is related to what is referred to as expectancy. If people believe that they have the capability to accomplish a task, they will have a better chance of persisting than if they are uncertain in their abilities to succeed. Even if the rewards are high, if people are not convinced they will succeed, they may have diminished motives to proceed. A third and related factor for staying on task is its perceived importance or value. This probably will have a less significant role for developers than people performing other types of tasks, in my experience. A developer’s concept of value is typically more related to conquering and delivering a functional working module. They are unlikely to be seriously influenced by the business value of the actual module as it probably holds less interest for them in many projects. It may help if they’re convinced that the module is absolutely necessary, but then if it wasn’t necessary they realize they probably wouldn’t be coding it in the first place. Developers however will almost certainly be sensitive to continually being assigned to code the mundane or boring modules.

Task Interruption

This is a topic that surfaces now and again in the software development sphere. It usually comes up when debating private offices versus cubes for developers and other technical staff that are required to get in the “zone” in order to work effectively. It seems quite obvious to me that this battle has already been fought (and lost) long ago. I see very few developers working from private offices, even small windowless ones, even though there is substantial research showing the benefit of quiet work areas for programmers. Technical people, the savvy problem solvers that we are, have responded mostly by adopting headphones to reduce open office noise levels.

Anyway, I will present here a brief rundown of the research on task interruption. It appears as though it is now generally accepted by most psychologists that task interruptions on more complex cognitive tasks inhibits performance and this seems rather intuitive as well. An interruption on simpler tasks has a smaller negative impact and on very simple tasks may actually improve performance slightly. There is some data to support the notion of optimal interruption times, which is basically between task steps (planning, execution, and evaluation). For personnel who work exclusively on computers, basically all software related workers, there are additional task interruptions that might potentially reduce productivity. These are primarily instant messaging, web assistants and email. Users who do not deactivate these applications may be bombarded with hundreds of messages and interruptions per day and this is clearly not conducive to elevated productivity.

How bad is the problem? Developers spend an average of 11 minutes on one task before being interrupted to deal with another, according to Gloria Mark of the University of California at Irvine's Department of Informatics, who has spent years examining developers' work environments. Amazingly, it then takes them an additional 25 minutes to return to the original task. This type of data, even if it’s only close to being accurate, is astonishing. How you can accomplish anything of significance in this type of environment is beyond my comprehension and certainly provides a case for more privacy for developers of some sort.

One of the principal arguments against providing private offices for software developers is that it will inhibit project collaboration. And while I agree with this up to a certain point, I think it’s mainly an excuse for saving office related expenses. Other reasons are political in nature. If you are required to provide private work areas for developers, whose next? Suddenly everyone will be expecting a private office is how the argument goes. The only corporate environment where I was able to attain private offices for my development staff was in a startup web based services company. Perhaps being a small organization and a part owner of the company was the difference.

If you run into the roadblocks mentioned here, your best alternative is to find a quiet, out of the way location in your facility and request the higher cube walls that help reduce the ambient noise. See the Reducing Resistance section in Chapter 7 for some ideas on how to best request these features.

Skip to main content