When I was in university I attended a couple of semesters of psychology. One of things that made the strongest impression on me was a graph the professor showed of human performance vs. motivation.  I googled around a bit to see if I could a copy of the curve, and I came across the following, which offers a little more interpretation than my psych prof. did, but does an excellent job of communicating the point.  It comes from an excellent post  at psyprogrammer.com.

.

As I understand it this curve comes originally from studies on factory productivity.  While it’s difficult to obtain bulletproof data on more difficult to quantify tasks like programming, my take from the psych lecture was that this curve extends pretty universally across all human activity.  This is not only matches against personal experience well, but seems to be pretty well accepted by the scientific community. An interesting aspect of the curve is it’s assymetric nature. Being slightly undermotivated has significantly less negative impact than being overmotivated by the same degree.

It’s an unfortunate truth that most people in managerial roles are woefully unfamiliar with this graph.  They typically overwork both themselves and their employees, to the detriment of productivity, all the while taking a macho sense of pride in how hard they work.  I can’t tell you how often I have heard people bragging about the excessive number of hours they work, while the rest of us groan under the weight of their emotional instability, error-prone work, and poor judgment.

Even when employees are disciplined about working reasonable hours, getting sufficient rest, and maintaining a positive work-live balance, excessive demands take a toll on productivity and this is no less true in the case of software development than it is any other task.  Software development is a kind of craft, in which intellectual discipline, creative thought and disciplined craftsmanship must all be combined to provide optimal results.    Managers who seek to whip their development teams up into a frenzy of panicked development wind up destroying their teams productivity.

I have all-too-often found myself in the position where management comes by the development teams on a regular basis to tell them “If we don’t develop feature X in time Y, we will go out of business.  The fate of the company is in your hands!”  Typically X and Y vary heavily, even within the same project, sometimes over very short time intervals.  Every time I have found myself in this situation, the deadline has been missed, and the company survived.  Besides resulting in skepticism and distrust in management, this has some very harmful effects.

In the best case, the programmers ignore the dire warnings, maintain a zen like attitude to their work and continue to strive to perform to the best of their abilities.  In this case the only harm is destruction of trust in management.  I’ve never actually seen this case,  but it is a theoretical outcome.  In the worst case people take the warnings/threats seriously, start hurrying production, and start sacrificing their personal time to the goals of the project.  Shortcuts are taken and technical debt is accrued in an attempt to make short term goals.  Developer get stressed and start to resent design discussions, make the discussions longer and less fruitful.  Developers get tired and their judgment and emotional equilibrium is impaired.  Stress leads to strife and illness.  In their haste developers stop taking time to mull their algorithms over, and errors creep in.  The time it takes to fix these haste-bred bug dwarfs the time it would have taken to calmly develop a correct implementation, which spirals the project further in stress, cynicism and despair.  Stressed out workers get sick, and feel pressured to work anyway so they infect their stressed coworkers leading to more unproductivity.  Eventually the project collapses under the weight of exhaustion  mistakes,  strife, and technical debt.  Actual results tend to fall somewhere in between these two extremes, but heavily weighted towards the latter outcome.

I meditate regularly.  I read books on Zen and try to set what I learn into practice.  I exersize religiously, eat healthy and have a very happy relationship.  Still I find myself slipping into unproductive stress levels when harangued by emotional and irrational managers.  Today I spent about an hour tracking down and debugging a completely moronic error.  I had written the following code:

/// if there is a next element, and it should be written, write a ",\n",
/// otherwise write a ;\n"
m_fstream << (( (i+1 < res.GetSize()) && shl::is_a_supported_type(res.GetItem(i+1).GetChoice()))?",":";")
<< "\n";

It actually does exactly what the comment says does, but it should in fact only write a semicolon if we are at the end of input.  This bug crept in under precisely the conditions I described above:  a manager ranting and raving on a daily basis about how we would go out of business if this feature wasn’t implemented yesterday, and why the heck is it taking so long and so on.  I was chastised for spending so long testing the code which was delivered, but the above bug wasn’t detected for two weeks, which implies that no-one noticed the error for two weeks.  Since this bug prevents data from being successfully loaded to the client application this casts a bit of doubt on how urgent the update really was.  In any case we still have to re-build and deploy the bug fix to the customer before he can use the feature, which means another hour or two of developer time, and a total of about 3 weeks of delay for the customer.  All because I felt stressed enough to get out of my zone and make a completely stupid mistake I would never make under less hurried circumstances.  Doubtless this is not the last such bug I will discover either.

All of this is an avoidable phenomena if one understands the relationship between motivation and performance.  If you really care about doing your best work, you won’t let yourself get overmotivated (stressed, hurried), and will try to keep yourself in the optimum zone.  Sadly this is terribly difficult if your manager is a stress junkie who perceives health productive workers as undermotivated.