It always took my friends and I until the middle of August to figure out summer. The grass had filled in, the water in the lakes and the pools had warmed up, we’d established new destinations to ride our bikes to, and we established new topics to argue endlessly about.
Then, seemingly only a day or two after we’d figured things out, “Back to School” banners would appear and suddenly our parents would start asking us about what supplies we’d need. We kids would be struck with the horror that in three weeks, at this exact minute, we’d be sitting at desks, not perfecting our behind-the-back Frisbee catch.
Something similar used to afflict my software projects. Just as we felt good about our requirements documents and the database structure, we’d have happy days lazily exploring our use cases. Then, seemingly only a day or two after we’d figured things out, Marketing and Sales meetings would appear, and suddenly our managers would start asking us about what final tasks we needed to finish.
We developers would be struck with the horror that in three weeks, at this exact minute, we were expected to have finished the error handlers, the first-use data initialization, and, horror of horrors, written an installer.
Oh, how I hated writing installers. Even with several third-party vendors trying to create a decent workflow, there was no escaping the sheer drudgery of developing an installer in the days before virtual machine “snapshots” of Windows became easy and quick. I once took an “easy money” contract for a moderately complex installer; I imagine that it took no more than 40 hours over the course of a few weeks, but the memory of grinding out the corner cases still sticks with me.
Installers are not the only necessary pain involved in deploying an application (there are also technical documents, final tests of non-debug builds, quadruple-checked distribution builds, etc.). The rise of Web applications has made many of these burdens less traumatic (teams that botch a deployment to the Web probably have less finger-pointing than the project I was on that ordered 5,000 then-quite expensive CDs that were missing one of the data files). But it is in the nature of humans to both put off unpleasant work and discount the effort required for unpleasant work.
This is one of the things explored in “The Upside of Irrationality,” a recent book by Dan Ariely. In it, he extends and finds practicality in the emotional biases that he explored in his best-selling prior book, “Predictably Irrational.” Ariely is a behavioral economist, which I take to mean is an economist who embraces the heretical position that humans are not perfectly rational evaluators of risk and reward.
Psychology experiments with non-intuitive results are inherently interesting, doubly so when the results seem to go against our self-interest. (Plus crossword puzzle enthusiasts need to stay up to date with words like “contrafreeloading,” a term that refers to “the finding that many animals prefer to earn food rather than simply eating identical but freely accessible food.”) Even experiments that support our expectations can be hilarious in their clarity: People paid to snap together “Bionicle” toys only to have them disassembled and handed back for the next round are less motivated than those given fresh sets and whose assemblages are put away for a (slightly) longer lifetime.
The first half of the book focuses on ways that we fool ourselves in the workplace, and it discusses several tropes that are familiar to software developers, particularly the “Not Invented Here” syndrome, how we overvalue what we make, and how bonuses affect motivation. The snap-together toy experiment had to do with the importance of feeling that one’s labor is meaningful, which I think certainly resonates with software developers.
The second half of the book focuses on more personal issues, such as adaptation to our circumstances, dating and empathy. In the section on dating, he discusses online dating sites as a “failed market,” with many obvious parallels to the online market for technical jobs (“Select the checkboxes that indicate your areas of proficiency…”).
The book is a quick read, and is padded significantly by footnotes and exhaustive acknowledgements (well, I read it on a Kindle, so “bulk” is a bit of a misnomer). By analogy, one can apply the book’s lessons to the success of agile development: the shift of tests from ancillary to integral, the incrementalism, the appreciation of aesthetics in code creation, and the emphasis on the coder as more than a faceless “unit of effort.”
Reading outside the strict necessities of work and education is one of the joys of summer, and Ariely’s book works nicely at the beach.
Larry O’Brien is a technology consultant, analyst and writer. Read his blog at www.knowing.net.
