Posts Tagged ‘software’

The Feminine Side

Monday, February 28th, 2011

At the recent Interaction Eleven conference in Boulder CO, Cheryl Platz gave an excellent presentation on ways to encourage young girls to study science, technology, engineering, and math (STEM) in school. Cheryl’s talk highlighted the importance of this, as the number of young women so choosing has dropped dramatically since the early 1980s, and the field needs all of the bright contributors it can recruit, regardless of gender.

I agree wholeheartedly with Cheryl’s remarks, and I support her recommendations without reservation. There is indeed some sort of barrier that discourages young women from getting into the technical professions, and it is well worth tearing it down.

Computer Engineering Barbie

But something about the presentation bothered me. After listening awhile, I realized that I was feeling the “framing effect”, a well-known cognitive bias, wherein the way a question is worded affects the way people answer it. Cheryl’s insistence that girls could enjoy studying math and science sounds right to me, but the way her argument was framed seemed to blame the girls for the shortfall.

While I earnestly support the idea that more girls should study math and science, I believe that the problem instead belongs to employers, educators, and the institutions they lead. I believe that the STEM disciplines would have more success with young women if they developed a stronger feminine side.

Rather than simply “boys” versus “girls”, I prefer to think of personal inclinations in terms of one’s “feminine side” and “masculine side”. I believe that all men and all women possess both sides in varying degrees. I am proud of my strong feminine side, and I know many women whose strong masculine side makes them tough as nails.

What’s more, there are many men and boys who are more comfortable in the soft studies and who eschew the harder sciences. There are many young men who struggle with math, but who could make excellent contributions to the fields of software development, technical literature, interaction design, visual design, cognitive and behavioral studies, and other closely related fields (for example, that would describe me).

I believe that girls reject math and science not because they are too girly, but because the purveyors of STEM education are too manly, or more accurately, too pointless and boring from the feminine point of view.

There are very real differences between the sexes, and these appear at a young age in all children. There is a large and growing body of literature in the fields of evolutionary and cognitive psychology that prove and illustrate these different ways the sexes behave in similar situations.

Women are quite capable of high achievement in STEM subjects, but they are disinterested because their motivations are different. Platz asserted that while men are content to learn math or science for the subject’s own sake, women see those disciplines merely as a means for achieving broader human goals. Those goals are what motivate the feminine approach, and when the subjects are taught in isolation, they often lose interest.

What’s more, I don’t believe that the hard sciences discourage only girls; I believe that they also discourage those with a well-developed feminine personality.

This is admittedly a semantic quibble, but the framing effect is a very real thing, and the language we use powerfully influences our decisions. And when the feminine side is strongly influenced to stay away from science and technology, our entire society suffers. A solely masculine discipline is a weak and one-sided discipline.

One could make a strong argument that the feelings of frustration and failure people get from using technology were caused by our purely masculine approach to software design. Almost all of our digital artifacts are designed and built by men (and a few women with strong masculine sides) inside organizations led by the same, who learned their discipline from masculine teachers within masculine institutions using curricula and methods that embody strong masculine principles.

Bringing stronger feminine values and more feminine ways of thinking to science and technology will bring a larger, more human scale view to our disciplines. The feminine side approaches problems and group dynamics in a way that is very different from the masculine way. When some minor catastrophe occurs at work or play, I have seen groups of men standing around demanding “Who did this?” and “Who’s going to fix this?” When that same catastrophe occurs amid a group of women, they ask “Did I cause this?” and “What can I do to fix this?” This positive, supportive attitude of women transforms the whole sense of teamwork and accomplishment.

It’s certainly possible to go too far, as groups of only women can be as biased and problematic as groups of only men. By far, the strongest and most effective teams are the ones composed of both men and women, with strong masculine and feminine sides. The whole nature of the group changes for the better with mixed gender teams. When there are at least two members of each sex in a group, the dynamics improve dramatically. A recent study gives some empirical credence to my personal observations.

Unfortunately, almost the entire spectrum of education in computer and software subjects is taught in glacial isolation from any practical application that improves people’s lives. The masculine side says “Computers are great because they can do anything!” while the feminine side says “I’d be very interested in computers if you could just tell me one useful thing they can do!”

I believe that the greatest burden of responsibility for bringing women into STEM education lies with the academic establishment. Young girls know who they are and what they want just as clearly as young boys do. As Cheryl noted in her talk, women are capable and willing of engaging with technology if it gives them command of something relevant in their lives. When educators connect their disciplines to the larger world, girls will be the first to see it, value it, and join up.

Many practitioners today seek redemption in a deeper understanding of the technical tools we use to build software. But that is such a masculine interpretation of the problem. Rather, I believe that a more worthwhile wellspring lies in understanding how human beings think and behave and what motivates their actions. That is, if the disciplines of science, technology, engineering, and math were to develop a stronger feminine side we’d not only see a lot more girls entering our fields, but our fields would be much better for it.

HTML Smokestacks

Tuesday, February 1st, 2011

HTML is to our era as smoke-belching industrial stacks were to the 20th century.

HTML Smokestacks

Changing Platforms

Sunday, January 30th, 2011

In the last half-dozen years one of the most remarkable things to happen in the world of software development is the transformation of the development platform of choice.

Every modern development shop I visit these days has programmers using a Unix-variant operating system. This is unsurprising, as Unix is the only OS really developed by and for programmers. What is surprising, nay, astonishing, is that this Unix is running on Apple Macintosh computers. Apple has never had much clout in the development community, and serious business application programmers have, for the past 25 years, used PCs running MSWindows, or its predecessor, MSDOS.

Pair programming on a Mac

Recently, I’ve been reflecting on how this came to be. I believe that Microsoft first grabbed the developer market because they understood, respected, and cared for developers. They have lost that market because they apparently have forgotten those values and their concomitant skills.

In January 2000, Bill Gates stepped down as president of Microsoft, and Steve Ballmer took his place. Ballmer was then, and is still, a legendary salesman, a brilliant businessman, and he possesses abundant force of will. But Steve never really understood the pivotal role programmers played in the tectonic market shifts the way Bill did.

By the late 1990s, the growth of the Internet, the inevitable progression of Moore’s Law, and the commoditization of manufacturing moved the central mass of the marketplace away from the office desktop and towards the consumer and home computing.

So by the end of the oughts, a hat trick of forces has dethroned the development platform king. Ballmer’s lack of focus on developers, the easy availability of open-source Unix, and Steve Jobs’ prescient attention on the consumer, have combined to attract multitudes of programmers to a most unlikely platform.

Ballmer the salesman, in the meantime, has been trying aggressively (does Ballmer know any other way?) to penetrate the consumer market, but here he is up against Apple’s 30-year head start. Steve Jobs’ elevation of design and user experience above that of engineering is paying off. Microsoft can employ thousands of UX designers, but they will never have the juice to dethrone the engineering culture in Redmond.

Things I learned at Agile Up To Here*

Sunday, May 16th, 2010

After 25 years, it’s time to lose the Windows computer and get a Mac.

Good agile developers are self confident; confident enough to trust interaction designers to do interaction design without distrustful oversight.

There are lots of programmers who understand that relational databases are not the only approach to solving problems.

It is time to build software.

Test-driven-development isn’t fully understood. In fact, software testing isn’t fully understood.

When even the leanest developer in the room sees really high quality BDUF for the first time, they get all woo-woo and want some for themselves.

Getting good software built demands the contributions of many different personalities, competencies, and roles, most of which are new and as-yet ill-defined.

Two programmers pairing can create more and better code in less time than one programmer can (I already knew this, but it’s always good to see it in action).

Even this jaded old fart can still get excited about changing the world.

There are many undiscovered and unfilled product niches on the Web, and one of them is “quality”.

People want a leader with a vision.

Elisabeth Hendrickson (@testobsessed) is a magical woman. To paraphrase Tom Robbins, “she’s been around the world eight times and met everybody twice.” Like a great chef or symphony conductor, Elisabeth knows how to combine the unexpected to create the sublime. She brought together a dozen people from all over the country, each with different skills, background, desires, and expectations, and then she blended them together into a cohesive, happy, effective team.

The pre-written code I arrived with was called “legacy” with a grimace, and was quarantined until discarded. Moral: Non-TDD code is properly regarded like a ticking time bomb.

For interaction design, you can’t have too many white boards, made from porcelain-coated steel, firmly mounted to the wall. For agile development, that isn’t such a big deal.

Story-mapping is a major component of the bridge between interaction design and agile development.

Story-tracking software isn’t quite there yet.

Data-miners think differently. I don’t think like a data-miner.

The Union Pacific Railroad, headquartered in Omaha, is not as “Dilbert-y” as it might seem.

There’s an app for that.

Pointy-haired managers are soooo counter-productive.

While I cling to my tree-based books and papers, bit-based books and papers are actually more capable in many ways. Is my nostalgia based on familiarity rather than quality? Did you just feel the Earth move, too?

Social programming.

While everyone expounds breathlessly about browser-based apps, they still spend the lion’s share of their time using native, client-side apps.

Software patterns are a powerful tool.

Sometimes there’s a necessary part of a program that is just ugly. You can refactor or reconceptualize it, but instead of shrinking it, you’re just moving the ugly part around. I call this the “Irreducible Nugget of Ugliness”, or INU.

I love inventing new TLAs.

While easier than it used to be, it’s still hard for an old software guy like me to keep his hands off.

Some people are perfectly content to not know about the personas and they still get good work done right.

There’s nothing new under the sun.

At a granular level in software development, what used to be easy is hard, and what used to be hard is easy. At a broader level, creating software still remains one of the most difficult things you can attempt.

The power of web development and modern tools is so great that it tempts even me to de-emphasize the user’s goals.

I worry a lot about applying an indelible Sharpie to a precious whiteboard.

Face time is vital when you are creating. If you are creating a product, you need face time with the product team; if you are creating a company, you need face time with everyone in the company.

Flickr is a steaming pile of software.

The only way to really get to know individual people is by devoting attention and time to them. The only way to really get to know your craft is by devoting attention and time to it. This is most definitely not a coincidence.

There are still a few bugs in the system.

The road to mastery is simple: just imagine the problem-set as being far bigger than everybody else does, and then give it attention appropriate to its size.

When you’re in the groove, there’s no 9 to 5.

When you finish something, ring a bell.

Dale Emery (@dhemery) said “I can give you a silver bullet, but be aware that you might be the werewolf.”

Candy remains a powerful motivational tool in the software world. Or maybe it’s just that the brain requires lots of cheap energy.

When you own something, you lose a lot of perspective about it.

Product ownership is far too complex and important to be left to amateurs, even if they actually own the product.

It’s okay to sit down during a Stand-up.

When you are really good at doing some job, you are usually unaware of the important nuances that make you so good.

Establish one really big goal, then establish lots of little, intermediate tasks that will get you to your goal. Then celebrate each task as you achieve it.

Model-View-Controller.

At a certain point the barriers to entry fall so low that no excuses withstand scrutiny.

*Elisabeth Hendrickson has recently opened a new test-and-development training facility in Pleasanton CA called Agilistry. It’s bright and airy, well-lit and well-stocked, and it feels like home the minute you walk in. In order to publicize her new facility, she very generously hosted a week-long intensive learning exercise.

She invited eleven different people with widely varied skill sets, backgrounds, and interests. She challenged them to build a website in five days using the best practices of interaction design, agile programming, and test-driven-development. We christened it “AgileUpToHere” (#au2h) and it exceeded everyone’s expectations (you can see our results here.

Since it was my 15-year-old homophone web site that was being rebuilt, I nominally played the role of product owner, but I was an observer, an instigator, a goad, and a participant. It’s hard to remember when I had so much fun or learned so much.

If you want to learn to be great, I strongly recommend Elisabeth and Agilistry.

Why Native Apps are Still Important

Tuesday, March 30th, 2010

While the iPad is a new platform, it is the moral equivalent of the desktop platform, only more portable. It has the kind of easy to use operating system that Microsoft could never, ever have created.

I’m not a big fan of the Apple closed universe, but the iPad will finally bring computing to the masses, simply because the average person will be able to run native apps without needing an IT department on call 24/7.

Everybody I know spends most of their time using native apps. The Web is just a transport layer, after all.

Stop Software Patents

Wednesday, March 24th, 2010

It’s time to put an end to software patents. Instead of helping, they hurt software inventors and hamper technical innovation. Software patents assist big corporations like Microsoft, Google, IBM, and Cisco while hindering garage startups and independent inventors, as consumers pay billions to support this anti-competitive infrastructure.

Please do not tell me that software patents protect the interest of software innovators. I’m a software innovator and I know better. For over 35 years I’ve invented, designed, and developed software. Virtually my entire livelihood comes from my original, patentable ideas, and the uncontrolled expansion of software patenting has only made independent innovation more difficult and more expensive.

The common mythology is that patents are a shield for the small-time, independent innovator, protecting the little guy against the predations of the big, moneyed corporation, allowing him or her to get compensated for his invention. Nice idea, but in reality the exact opposite is true.

It isn’t so much that software patents curtail innovation—stopping innovation would be like trying to stop sex or music or breathing—but it drives independent innovators out of their garages and into the research arms of big companies where the returns for invention go to the corporation, and not to the individual inventor.

Patents are not cheap, but not prohibitively expensive. They cost about $50,000 and take a year or two of patient filing and adjudicating. But a patent is of no use unless you are capable of defending it. That is, when someone infringes on your invention, you have to take them to court, even though this can cost millions. But if you don’t sue, you can lose the patent. For a one-man-garage-shop, that is out of the question, but not so for a big corporation, who likely has an entire department filled with intellectual property litigators.

The software patent landscape is not level. All inventors are not equal, and the current patent laws merely serve to tilt the playing field even further.

2010-04-14: Here’s a relevant website: End Software Patents.

Software Craftsmanship

Friday, March 19th, 2010

A discussion today on Twitter (kind of an oxymoron, that) about craftsmanship, reminded me of this essay I wrote long ago. It was originally published in Visual Studio Magazine in 2003. Some of the stuff I tsk, tsk over is being successfully addressed by agile and post-agile thinking, but the nature and role of craftsmanship remains unchanged.

—-

Programmers are craftsmen and craftswomen. They are commonly thought—and frequently titled—engineers, but few working programmers “engineer” things. Most  build software. They craft it into existence.

I define craft the way the word was used hundreds of years ago, when a craftsman was a skilled expert who produced practical objects, and whose work was unique and highly valued. Only the wealthy could afford such finely made, custom objects. The Industrial Revolution elevated the engineer over the craftsman, and craft came to mean anything from sweatshop assembly to decoupage. The great engines of the Industrial Revolution were made of metal, powered by steam and electricity, and designed by engineers. The revolution’s ultimate fruit—mass production—was the antithesis of craft. Everyone could afford mass-produced items. Western society traded custom-fitting and superb quality for adequate quality and egalitarian access (an excellent trade, I believe).

The assembly-line worker was neither engineer nor craftsman. Although literate, he wasn’t well-educated, and his job required only minor training. Sadly, the term “craft” was often associated with him, because he was the proximate creator of goods, and industrialization devalued the term. The craftsman’s reputation waned, and many preindustrial crafts have disappeared.

The engineer was the educated, trained expert who designed the manufacturing processes: the “engines” of industrialization. The engineer was clearly the most highly skilled person in the industrial age hierarchy. But engineers don’t actually build things. They solve complex and demanding technical problems necessary to building things but leave the actual creation to others. Engineers don’t build bridges; ironworkers do. Engineers don’t build automobiles; assembly line workers do. Engineers don’t build software; programmers do.

The industrial age is over, and we’re in the information age now. Manufacturing still exists, but even a business sage as trusted as Peter Drucker says it’s no longer possible to differentiate your company by way of manufacturing. Even manufacturing companies don’t make money by creating things, but by using software to make sure they manufacture the right things, in the right quantities, at the right times.

The shift from steel to bits has been rapid enough to generate ample confusion about our modern roles. The most important builders today are programmers, and it’s only natural that they’d adopt a title such as “engineer” to reflect this status. Language influences our perceptions and our values so using the wrong job title can derail an entire profession. Programmers’ chief responsibility is creating product, not solving technical problems. Having chosen the wrong job description, our profession finds itself suffering from a profound misunderstanding of its role. The result is failed software products, executives who are terrified of programmers, costly tech support and training, and a fruitless quest for a cure in ever more obscure engineering processes.

Although programmers solve tough technical problems all the time, software isn’t mass-produced, and it’s definitely not “manufactured” by interchangeable, marginally trained assembly-line workers. But software’s unique nature was unforeseen by any industrial age thinkers. Software can be copied and distributed without limit, so it shares the egalitarian access of industrialization, but unlike washing machines or cloth, it can be custom-morphed and configured for each installation. This “mass-customization” is a new, purely information-age concept that was neither technically nor economically feasible in the industrial age. It resurrects the notion of craft in the preindustrial sense of requiring experts’ talent, training, and skill, focused solely on a practical outcome.

Engineers primarily devise manufacturing solutions and solve technical problems. They’re rarely responsible for the actual construction of things. For example, a structural engineer devises solutions that allow a building to stand firm, but she lives in a world of paper and mathematical models and won’t lift a finger to weld steel or pour concrete. It behooves the engineer to try numerous solutions, exploring dusty corners of the problem to find opportunities for improvement. It behooves the craftsman to stay on well-known ground and to avoid costly experimentation. The engineer works on paper prior to construction, and the craftsman builds the end product. The engineer throws away paper; the craftsman throws away time and money. Both are prized for devising creative solutions to difficult technical problems, but craftsmen are most highly prized for constructing sound artifacts quickly, efficiently, and expertly, with a minimum of waste and a maximum of predictability.

I asked a friend who supervises building construction how he defines “craft.” He said it’s characterized by a proclivity to think things through, to understand the problem fully, to have the necessary experience in the job, to get results with top-notch quality, and to meet the customer’s expectations. This last point is important, because it differentiates art from craft.

A programmer friend, describing how he is a craftsman, asserted that he works the way a sculptor or painter does. He was incorrect, but understandably so, because it’s easy to confuse craft with artistry. He was referring to the demanding techniques of construction, and the pride and personal satisfaction he gets from his efforts. But art rarely has a practical purpose the way that craft and virtually all software does. It’s an artist’s privilege to change the context, form, and meaning of her creation, but the external requirements placed on software can’t be changed simply because the programmer wishes it so, and there’s little room for the artist’s whims or wanderings in the programmer’s cubicle. Art can include craft, but the reverse isn’t true. Comparing a programmer’s work to an artist’s is a compliment, not a literal analogy. An essential ingredient in professional craftsmanship is knowing how to work within the box—a box that’s always defined precisely by detailed drawings and plans that an architect created and engineers vetted.

My late father was an electrician who knew his trade inside and out.  He was bright, though not formally educated. He would confound his supervisors occasionally when first arriving at a new construction site, because instead of diving into the wiring, he would look, and measure, and mostly stand and think. He was calculating mentally how to accomplish the wiring with the greatest efficiency of effort and material. One of his bosses said, “When Bob Cooper was just standing there thinking, he was being the most productive.” He was clever, creative, and proud, but he always respected that a great result did not, could not, include any redefinition of the problem. He knew that good craftsmanship meant fabricating the best component for the whole solution. He was not free to redefine the problem, but his efforts had to be a coherent part of a well-planned whole, a design. Above all, my father was a craftsman.

Commercial programming is clearly a craft. Unfortunately, the failure of our profession to recognize this has allowed two profound problems to grow. First, programmers almost never work to a plan. All craftsmen exercise their skill within a context well defined by detailed, written descriptions of the desired ultimate form. These plans are typically devised and drawn by an architect, a role rare in the software world. Architectural plans are necessary to ensure that the work of multiple craftsmen dovetail together, and that it meets the buyer’s expectations. Most contemporary programmers work only from a list of features and a deadline.

Second, programmers are almost never supervised. Craft is by nature detail-focused and deeply involving. Good craftsmen regularly work in a state of flow, so they must depend on others to make sure that their efforts merge with those of other craftsmen. The supervisors aren’t there to keep craftsman from dodging work, but to ensure that the big picture is tended to. A well-crafted building, for example, is more than an assemblage of sturdy walls; the walls must connect properly. The craftsmen can do this, but they rely on someone else to coordinate their work.

Many programmers are expressing dissatisfaction in their practice and I’m heartened by their resultant quest for ways to improve it. Extreme programming reflects a quest for supervision (from a pair programming partner) and for a plan (from the customer). Visual object-modeling tools such as Unified Modeling Language (UML) similarly seek to plan and supervise programming by applying powerful engineering tools. Although these can’t be viable substitutes, they indicate a strong awareness of the problem.

Our misuse of language and titles gives programmers license to let practical construction imperatives slip by and to focus instead on in vitro problem solving. Examining software in the light of the confusion between craft and engineering brings previously obscured causes of many common problems and their solutions to light. Unlike engineers, craftsmen create commercial software, and they need design plans and supervision to yield the results expected of them. Good engineers love their work because they love to solve difficult problems. Good craftsmen love their work because they love to make things. Good programmers must do both, but they’re judged ultimately on the efficacy of what they make, not on the cleverness with which they make it.

Software Is Hard

Thursday, March 11th, 2010

There are a couple of big items on my blog to-do list. One of them is to write an essay about how hard it is to write software. Another to-do item is to write a review of Scott Rosenberg’s remarkable 2008 book Dreaming In Code.

Until I get around to these two tasks, you will find Kyle Wilson’s 2007 essay “Software Is Hard” to be a good start on both topics. Wilson is a software engineer in the game industry; and there is no harder toil than programming in the game business.

The blogosphere is dominated by the opinions of software developers who build browser-based software. Certainly this is important and valuable software, but it remains just one of the many variants. Wilson and Rosenberg examine the creation of game engine and email server software, respectively. Both of these categories of software are qualitatively, quantitatively, and morally different from iPhone apps or e-commerce.

The recent successes of agile methods have led many to see them as a universal panacea. Because a new social networking website application can be built very fast using Scrum and TDD, many developers believe that all software can be built just as fast with these agile methods. But the demands of military or medical or game software are very different from those of tweeting or shopping.

There is no doubt that agile development is a significant step forward in creating software. It is certain that agile thinking will eventually permeate every aspect of software development. But it would be a mistake to think that every variety of software construction will be affected equally or that there will be any semblance of uniformity of agile practice across the full range of programming. It’s easy to extrapolate universal truths about software development by examining your own software development work experience, but this is a sinister trap. The world of software development is far broader than most people realize.

Even though Fred Brooks’ famous aphorism that there is “no silver bullet” in software is quoted frequently by agilists, they use it only as a weapon against diehard supporters of obsolete waterfall development methods. They often don’t see that it applies to agile methods just as profoundly.

Book Review: On the Origin of Stories by Brian Boyd

Wednesday, February 17th, 2010

Darwin’s theory of evolution is generally regarded as one of—if not the—most important scientific revelations in history. Even amateurs like me give it props, but respect and understanding are two different things. It’s particularly difficult to wrap your head around the theory’s profound implications when you are one of those evolved forms. To put it another way, while humans have evolved many powerful mental abilities to help us understand the world in which we live, we haven’t evolved any particular mental ability to let us clearly see ourselves in an evolutionary perspective. We struggle to grasp what it really means to be an animal, driven by instinct, composed of an unordered set of adaptations, and not the rational, clear-headed, self-directed person we imagine ourselves to be.

It’s true that humans are animals with a highly evolved set of cognitive powers, but that doesn’t mean that we are without instinct or without invisible motivations rooted in our survival adaptations. Not only do humans have a history of ignoring the effect of their adaptations, but our recent history shows us misunderstanding and abusing them. In the middle of the twentieth century, the pseudo-science of eugenics was used as a justification for genocide. Academia, in recoiling from eugenics, banished any enquiry into how Darwinism might affect Homo sapiens. For at least a half-century, serious enquiry into the evolutionary basis of human behavior was suppressed. Unfortunately, in the vacuum, touchy-feely psycho-babble like Freudianism dominated the landscape of study.

The passage of time as well as such technical tools as computer-aided-tomography has finally allowed serious scientists to turn their attention to human evolution, provoking only ragged outbursts of hysteria. The last couple of decades have seen a tremendous explosion of fascinating and important work in the many new evolution-based fields of study.

Enough researchers have probed the subject with sufficient rigor and repeatability to elevate cutting-edge, evolutionary psychology to the level of “hard” science. We are not just working with theories and metaphors any more. What’s more, there are many skilled writers bringing scientific findings to the amateur reader. Brian Boyd’s new book, “On the Origin of Stories”, subtitled “Evolution, Cognition, and Fiction”, is a fine example.

The book is a fascinating enquiry into how humans think, behave, and conceive of the world and each other through the startling lens of our evolved survival mechanisms. Boyd says that “Minds exist to predict what will happen next.” What sets this book apart is its focus on the role of art, and particularly the art of telling not-strictly-true-stories, in shaping human behavior and civilization.

Some readers will object to Boyd’s pedantic, step-by-relentless-step defense of fiction—and all art—as an evolved behavior. But political correctness, in its unyielding fight against eugenics, still actively combats contemporary researchers when they look human-ward. To make his case, Boyd clearly feels that he must not only examine art from an evolutionary perspective, but he must also examine evolutionary biology as well, which he does doggedly, but effectively. Boyd explains, “Since evolution challenges deeply held intuitions about our special place in the world, since the controversies have been sharp and the confusions and misrepresentations profuse, we have to tread carefully.” Even if you are not a hyper-sensitive, political-correctness Nazi, or a bible-thumping Creationist, seeing human nature through Darwinian lenses can be challenging to one’s self-image, and while Boyd’s methodical arguments are demanding, they are not unwelcome.

I’m neither an academic nor a scientist, but a designer and builder of software, which means that I endow high-technology products with human-facing behavior. Understanding how humans conceive of the world around them, and how they are motivated, is an essential skill for anyone in my line of work.

Historically, computer programmers have ignored all of this human stuff and instead immersed themselves in the abundant technical minutia of programming. Of course, the software they wrote was heartbreakingly difficult to use. It took many years and many tears before an awareness of the linkage between bad software and misconstrued human nature emerged. And sort of like those vestigial defenders against eugenics, there remain many who resist the idea that evolutionary psychology plays a role in the design of software. Yet, because evolutionary psychology directly addresses human motivation, it is arguably the single most useful tool for understanding and designing the form and behavior of software.

Not only are Boyd’s opening chapters on evolutionary psychology an excellent précis of the territory, but his focus on the evolutionary origins of storytelling are even more useful to the software designer. Narrative, or storytelling, is a vitally important tool both for the design of behavior and for the communication of that design.

Boyd gives us a vocabulary for understanding storytelling. He shows how humans conceive of the world through stories. Our relations with others are framed by our physical memory into narratives with characters and events to enable future recall. Our values and our perceptions are based on these storytelling mechanisms. We imagine the world through narrative eyes: plot and character, event and intent, attention and pattern, anticipation and surprise.

Storytelling is what allows the software designer to imagine real people in front of our software creations. Storytelling allows us to see their instinctive human motivations and perceptions at work as they manipulate the interfaces that we design. Storytelling allows us to share our abstract designs with others who must implement them.

The evolutionary basis of art is probably the least examined, and least understood, area of contemporary evolutionary study. Even Stephen Pinker’s 1997 book, How the Mind Works, a sweeping overview of the field, fumbled the art ball. Pinker posed two theories. The first being that art is merely a by-product—or vestigial remain—of our big brains used for other, more important things. Pinker’s second argument is that art is used to attract mates. Being otherwise without purpose, owning an expensive painting, for example, communicates one’s wealth, and by extension, ability to nurture offspring.

Boyd kindly but thoroughly dismantles both of Pinker’s arguments. Art as by-product falls to the argument that evolution quickly evolves away from costly but useless abilities, citing the way cave-dwelling salamanders soon become sightless. The art-as-sexual-attractant is a more resilient argument. Darwin described such mechanisms, like a peacock’s tail, calling the process “sexual selection.” Boyd argues,

“If art were sexually selected, this would predict that it is overwhelmingly male and directed to females, developing rapidly at puberty, peaking just before mate selection, and diminishing drastically afterward. But mothers of all cultures sing to infants; infants prefer their mother’s singing to their fathers; infants of both sexes engage in cooing and singing, clapping, and dancing as soon as they can.”

It is easier to recognize human adaptations when we look at the simple, fundamental manifestations of art in human behavior than it is to discern them by gazing at a Vermeer or a Klee.

Boyd says “Evolution by natural selection is a simple principle with staggeringly complex and unpredictable results.” No where is this more true than that uniquely human affect, art.

“Despite its many forms, art, too, is a specifically human adaptation, biologically part of our species. It offers tangible advantages for human survival and reproduction, and it derives from play, itself an adaptation widespread among animals with flexible behaviors.”

Some people might find it hard to believe that something instinctive and important for human survival could also be so entertaining, enjoyable, and often inconsequential. But humans persist in having sex even when there is no chance for reproduction.

Boyd also argues that just because something serves a purpose, it doesn’t mean that it can’t serve others as well.

“Eyes evolved for vision, but we also use them for communications: hence our contrastive white sclera, which highlight the direction of another’s gaze, and our highly refined capacities for registering and inferring attention and intention from others’ eye direction. That we can now intimidate others with our stare does not refute the fact that eyes evolved for vision.”

The core of Boyd’s case is that art is a form of cognitive play. “We can define art as cognitive play with pattern. Just as play refined behavioral options over time by being self-rewarding, so art increases cognitive skills, repertoires, and sensitivities.” The role of play is to safely practice what we will eventually need to survive. We play at fighting because eventually we will fight for our lives. We play at storytelling because eventually the real story that plays out around us will determine our fitness to succeed.

Storytelling, and all art, is the tool and training ground for humans to learn and practice social interaction. Humans develop a sense of “event comprehension” while still in the cradle. Events, of course, are a key element of plot and narrative.

The brain works by strengthening paths that are used repeatedly, so we need to practice those skills necessary for survival. In the ultra-social world of humans, perceiving and understanding the honesty and intent of others is paramount.

Boyd describes it by saying,

“A work of art acts like a playground for the mind, a swing or a slide or a merry-go-round of visual or aural or social pattern. Art’s appeal to our preferences for pattern ensures that we expose ourselves to high concentrations of humanly appropriate information eagerly enough that over time we strengthen the neural pathways that process key patterns in open-ended ways.”

The portion of our brains that are uniquely human, the neocortex, is constructed differently from the older parts of the brain, and it functions differently, too. It works more like an executive, integrating signals from widely disparate facilities. This necessitates a mechanism for aiming the executive. Boyd asserts that this mechanism is attention.

Attention is what allows us to focus on the tiny behavioral cues of others, to determine their intent and to assess their validity. Conversely, it allows us to alter our behavior, so that the cues we send to others suit our own intentions. Stories become cognitive exercises that focus our attention on “perceived patterns of behavior in order to infer intent.”

Attention is remarkably important to humans. To a significant extent, attention is the true currency of human civilization. The maxim “survival of the fittest” seems to say that all of us evolved beasts are constantly in competition not only with our surroundings, but with each other. That is certainly true, but it is also true that we cooperate, and we often do so across large populations. By definition, any social species must cooperate effectively, and humans are exceptional in this regard.

“All social species prosper more together than alone, or they would not remain social, but humans take this to another level, ultrasociality, the most intense cooperativeness of all individualized animal societies. Not endowed by nature with formidable strength or speed, we have been able for hundreds of thousands of years to coordinate our activity sufficiently to kill large prey—and, for thousands of years to construct pyramids or cathedrals and settlements of thousands or even millions.”

Cooperation itself is a multi-faceted thing. At the lowest level is mutualism, wherein simply being near others of the same species is helpful; watching for predators, for example.

The next step, active cooperation, explains why parents look out for their children. But in this case, the direct tie to genes is obvious. How can cooperation be explained when those involved don’t share genes? Deduced from game theory, the answer is termed reciprocal altruism: “I help you in the expectation that you may help me later.” Of course, it is still very easy to cheat, so humans have evolved many cognitive tools for the detection, prevention, and punishment of cheaters. These uniquely human tools include

“Sympathy, so that I am inclined to help another; trust, so that I can offer help now and expect it will be somehow repaid later; gratitude, to include me, when I have been helped, to return the favor; shame, to prompt me to repay when I still owe a debt; a sense of fairness, so that I can intuitively gauge an adequate share or repayment; indignation, to spur me to break off cooperation with or even inflict punishment on a cheat; and guilt, a displeasure at myself and fear of exposure and reprisal to deter me from seeking the short-term advantages of cheating.”

Boyd says, “Rather than merely taking these emotions as givens, we can account for them as natural selection’s way of motivating widespread cooperation in highly social species.”

One of the more fascinating aspects of this book is its description of the empirical tools employed by evolutionary psychologists to explore their theories. Boyd describes the work of evolutionary psychologist Leda Cosmides attempting to discern the workings of the human anti-cheating mechanism. She found that although people struggled to solve problems in logical reasoning when presented in abstractions, people solved them easily when they were presented in terms involving cheating in social exchange.

Behaving in non-selfish ways is logical only if you see the bigger picture of cooperative groups, but people don’t think of groups, they simply behave according to their emotions. And those emotions are mechanisms that function regardless of logic. Our justice-detection mechanism, key to mutual altruism, often makes us behave in ways that defy the assumptions of logicians.

“In one experiment, the dictator game, two strangers play for (usually real) money, say $100. I, as dictator, must offer you a share. If you accept the division, both of us keep our agreed portions. If you reject the offer, neither of us receives anything. In terms of strict economic rationality, an offer of a dollar, even a cent, would leave the second participant better off, and should therefore be accepted. But … often if the sum offered is only a little under $40, the respondent rejects it. A sense of fairness in social exchange overrides the rational calculation of gain. We have evolved not to be ‘rational individuals’, profit maximizers, but social animals, holding others to fair dealings even at our own cost.”

Stories originated in the need for informing our justice systems; for monitoring people’s compliance with fairness. Gossip is the simplest and most widespread form of this, and ultimately, all fiction derives from it. Out of such simple mechanisms grow mighty civilizations.

Slowly, methodically, Boyd steers us away from conventional thinking about the role of art and narrative. The importance of art can be seen in its ubiquity. “Art” he says

“(1) is universal in human societies; (2) it has persisted over several thousand generations; (3) despite the vast number of actual and possible combinations of behavior in all known human societies, art has the same major forms (music and dance; the manual creation of visual design; story and verse) in all; (4) it often involves high costs in time, energy, and resources; (5) it stirs strong emotions, which are evolved indicators that something matters to an organism; (6) it develops reliably in all normal humans without special training, unlike purely cultural products such as reading, writing, or science. The fact that it emerges early in individual development—that young infants respond with special pleasure to lullabies and spontaneously play with colors, shapes, rhythms, sounds, words and stories—particularly supports evolutionary against nonevolutionary explanations.”

As I read this book, I assumed that Boyd was a scientist; an evolutionary biologist. At some point I glanced at the dust jacket and was surprised to find that he is a professor of English in New Zealand, and that he is “the world’s foremost authority on the works of Vladimir Nabokov.” The book is divided in two equal portions. The first half is pure evolutionary psychology, and I found it quite fascinating and informative. In the second half of the book, Boyd-the-English-Professor emerges. He presents two timeless works of literature from the evolutionary point of view. You can get a glimpse of his dual nature just by knowing that his selections are “The Odyssey” by Homer, and “Horton Hears a Who” by Dr. Seuss.

While I devoured the first half of the book, the literary second half seemed prolix and redundant to me. You may have a different experience. In any case, I recommend the book to anyone interested in evolutionary science, and in particular to any practitioner in the world of human-facing software.