PowerPoint is NOT the Enemy

The “tl;dr” Version (or: “The Executive Summary”)

High-ranking officers in the U.S. military say that PowerPoint makes them dumb. I say that their reliance on technology for technology’s sake makes them dumb. I make use of an episode of The Office to illustrate my point and the Milliennium Challenge war games exercise as evidence. I then wrap up the article with some suggestions on how best to use PowerPoint (or Keynote, or any other slideware).

The U.S. Military vs. PowerPoint

The U.S. military's complex "Afghanistan Stability/COIN Dynamics" slide

“When we understand that slide, we have won the war,” said General Stanley A. McChrystal, the leader of American and NATO forces in Afghanistan, about the slide above.

This slide appears not only in a PowerPoint deck meant to illustrate the complexity of American military strategy, but also in a New York Times article titled We Have Met the Enemy and He is PowerPoint. Here’s an excerpt:

“PowerPoint makes us stupid,” Gen. James N. Mattis of the Marine Corps, the Joint Forces commander, said this month at a military conference in North Carolina. (He spoke without PowerPoint.) Brig. Gen. H. R. McMaster, who banned PowerPoint presentations when he led the successful effort to secure the northern Iraqi city of Tal Afar in 2005, followed up at the same conference by likening PowerPoint to an internal threat.

“It’s dangerous because it can create the illusion of understanding and the illusion of control,” General McMaster said in a telephone interview afterward. “Some problems in the world are not bullet-izable.”

In General McMaster’s view, PowerPoint’s worst offense is not a chart like the spaghetti graphic, which was first uncovered by NBC’s Richard Engel, but rigid lists of bullet points (in, say, a presentation on a conflict’s causes) that take no account of interconnected political, economic and ethnic forces. “If you divorce war from all of that, it becomes a targeting exercise,” General McMaster said.

Commanders say that behind all the PowerPoint jokes are serious concerns that the program stifles discussion, critical thinking and thoughtful decision-making.

That’s right, what’s hurting the military is not the complexity of its mission (which the slide above was meant to illustrate), an amorphous, distributed opponent, the lack of an exit strategy, the faulty intelligence, the bad assumptions (“We’ll be welcomed as liberators!”) or equipment issues (“You fight with the army you have, not the army you want”); it’s PowerPoint.

As a techie who does a lot of presentations, I’m aware of the ways that PowerPoint can be abused, but I think that in this case, I believe that this is a case of a bad workman blaming his tools.

PEBGAC (Problem Exists Between GPS And Chair)

Michael Scott from "The Office"

I’m taking a risk by comparing the commanders of the U.S. military to Michael Scott, the clueless boss from the U.S. edition of The Office, but there’s a parallel.

The episode that best epitomizes Michael’s loathing of and failure to understand technology is Dunder Mifflin Infinity, the one where Michael decides that the best way to win back customers that Dunder Mifflin lost to the competition is by by hand-delivering gift baskets to them. This is in contrast to the ideas of his new boss, Ryan (the former temp), who wants to use technology – Blackberries, email, a sales website and yes, PowerPoint – to boost the company’s sales.

After a day of failing to win back former customers with the gift baskets, Michael misinterprets his GPS’ instructions and drives his car straight into a lake. When they return to the office, Michael announces to everyone:

I drove my [bleep] car into a lake. Why, you may ask did I do this?  Well, because of a machine (looks at Ryan). A machine told me to drive into a lake. And I did it. I did it because I trusted Ryan’s precious technology.

At the end of the episode, in one of those segments where the characters talks to the documentary crew following them, Michael says:

Everyone always wants new things. Everybody likes new inventions, new technology. People will never be replaced by machines. In the end, life and business are about human connections. And computers are about trying to murder you in a lake. And to me the choice is easy.

General McChrystal’s blaming PowerPoint sounds a lot like Michael’s blaming his GPS.

At this point, you might be thinking “Well, Joey, that’s fine and dandy for you to cite a fictitious example of blind reliance on technology by a fictitious character who is a buffoon, but how about citing something real, related to the military and featuring competent people?”

To which I would reply: “Very well, then.”

Millennium Challenge

The control room at Millennium Challenge

The U.S. military got an object lesson about their overreliance on technology for its own sake when they got pantsed in a war games exercise named Millennium Challenge. The exercise took place in the summer of 2002, in that period just after 9/11 when the Bush administration was seriously contemplating an attack on Iraq as the next phase in the War on Terror. To test their military capability and their high-tech approach of “network-centric warfare”, which included vast computer systems for tracking and gathering information on the battlefield, the U.S. armed forces staged the largest war game, using a combination of computer-simulated and real-life forces (including 13,000 real troops and a small set of real warships and planes), at the cost of $250 million.

The exercise featured two teams:

  • Blue Team: The good guys, representing the United States, who were in possession of an array of advanced vehicles, weapons and technology
  • Red Team: A rogue Middle Eastern state with the sort of arsenal that one would expect a banana republic-ish oil state to have

By rights, Blue Team should’ve easily trounced Red Team, but Red Team was under the command of Lieutenant General Paul van Riper, a marine and Vietnam vet with a keen tactical sense and an almost MacGyver-like ability to make the best use of limited resources. He confounded Blue Team by using unorthodox tactics:

  • Knowing that Blue Team would be monitoring radio chatter, he used messages encoded in calls to prayer that were broadcast from the minarets of mosques and carried by couriers on motorcycle.
  • He gave launch orders to planes not by radio, but by using a simple set of signalling lights, not unlike those used by the U.S. in World War II.
  • He positioned innocent-looking civilian aircraft and boats in the Persian Gulf which were first used to locate Blue Team’s ships and then to destroy them, either in suicide attacks or by using them as launching points for Silkworm cruise missiles.

At the end of the skirmish, Blue Team was badly hit, with 16 ships either destroyed or disabled and 20,000 dead personnel. Blue Team may have had the technology, but their overreliance on it had cost them the battle, and possibly the war.

In spite of this defeat, Blue Team was declared the winner. Using the excuse that “such tactics would never be used in real life”, the war game was reset, the sunken ships re-floated and the troops resurrected. The exercise was conducted anew, this time with many constraints put on the Red Team that essentially mandated that the Blue Team would win. Van Riper, frustrated with the “scripting”, quit after four days under the new rules of engagement, and later said:

Nothing was learned from this. A culture not willing to think hard and test itself does not augur well for the future.

A phrase I heard over and over was: ‘That would never have happened,’ And I said: nobody would have thought that anyone would fly an airliner into the World Trade Center… but nobody seemed interested.

There’s very little intellectual activity [in Joint Forces Command]. What happens is a number of people are put into a room, given some sort of a slogan and told to write to the slogan. That’s not the way to generate new ideas.

Blue Team had advanced technology, vehicles and weaponry, and those advantages gave them a false sense of understanding of the situation and a false sense of control. Just as they made a mistake-in-the-large wand refuse to see the error of their ways in Millennium Challenge, they are making a mistake-in-the-small and refuse to see the error of their ways with PowerPoint. It’s far easier to blame something else, whether it’s General Van Riper or presentation software.

Drunks and Lampposts

"Hangover Pete" -- a toy drunk leaning against a lamppost

The U.S. military’s PowerPoint problem is that same problem that a lot of civilian organizations, Microsoft included, have. It’s that they’re misusing PowerPoint in the same way that drunks misuse lampposts: as a crutch, rather than as a source of illumination. Instead of coming up with ideas and then illustrating them with PowerPoint, they’re taking random bits of knowledge, fitting them onto slides and then hoping that ideas will coalesce from them.

PowerPoint comes jam-packed with features that make it easy to fill up empty slides or spend time working on the appearance rather than the content of your presentation. Bulleted lists, which are practically PowerPoint’s default mode, make it too easy to turn your slides into cue cards that you read aloud to your audience. SmartArt makes it incredibly easy to arrange words into flowcharts and diagrams – so easy that people often end up tweaking those flowcharts and diagrams rather than the ideas behind them. Transitions make it easy to provide some razzle-dazzle to cover up the fact that your slides are bereft of content.

The problem caused by these features isn’t unique to PowerPoint. “Style Over Substance” is a trick that’s as old as human communication itself, and there are other tools that lead to the same problem:

  • Word processors: In his book Counterblast, Marshall McLuhan wrote that the typewriter changed writing. The increased speed it offered led to less-planned, more stream-of-consciousness writing; the additional speed and added fluidity of cut-and-paste that word processing provides amplifies that effect. The control over formatting that word processing offers has led many people to spend more time working on the appearance of their documents instead of the content.
  • Graphic design: Photoshop and Illustrator have taken a lot of the “friction” out of graphic design, which leads many people to skip the “rough sketch” phase of graphic design and leap straight to working on the final image. As with PowerPoint and word processing, the control they offer often leads people to focus on the tool rather than the work they are trying to create with it.
  • Music: The ease with which something polished-sounding can be created has drained musicality from today’s pop tunes. These days, it’s not unusual to hear a tune that’s essentially a single chord built on a one-bar loop. Many producers of hit singles – it’s a bit of a stretch to call them “musicians” – spend more time tweaking the sounds rather than crafting a melody. And don’t get me started on the lyrics.
  • Movies and television: As hokey as they were, the Star Wars episodes created in the late 1970s and early 1980s, episodes IV, V and VI, had memorable stories and characters. The trilogy made in the late 1990s and 2000s is a pale shadow of the original because they were too focused on CGI and special effects to make interesting characters or put some effort into storytelling.
  • Software: Tools that let programmers build user interfaces through dragging and dropping have long been blamed for the dumbing-down of programming. While it isn’t necessarily so, I’ve seen that these programs enable many mediocre programmers to create something that looks reasonably polished on the surface and other programmers to spend more time tweaking the look and feel instead of the underlying code.

Avoiding the U.S. Military’s PowerPoint Mistakes

Focus on the Presentation Rather than the Slides

PowerPoint make it easy to create slides. The problem with that it that it leads people to focus solely on the slides. As a result, they think that making a presentation is simply about making the slides, and once that’s done, they’re done. Not so.

The act of you presenting ideas to your audience is the presentation; the slides are there to provide the visual component. You should consider the following:

  • What should the audience take away from your presentation? What’s the one thing your audience should remember long after the presentation is over?
  • Use slides for conveying visual information. That’s what they’re for. Use graphs to provide context and meaning for statistics. Use pictures so that the audience can see what you’re talking about. Use flowcharts to make complex processes easier to understand.
  • Use slides as a means of underlining what you’re saying. Rather than showing the audience a slide and then explaining what’s on that slide, use your explanation as the basis and use the slide as an enhancement. A great example of this is the “The Word” segment on the Colbert Report.
  • Harness the power of stories. Stories resonate with people. Instead of using slides, why not explain your ideas using an illustrative story?
  • Show, don’t tell. At DemoCamp, we forbid people who are presenting their software project from using PowerPoint or other slideware. Instead, we insist that the only thing they’re allowed to show on the big screen is their software in action because we feel it’s a better way to do a software presentation. In the EnergizeIT tour that we just conducted in 21 cities across Canada, we did a presentation that had almost no PowerPoint – it was all demos with live code and data, and audiences loved it. Perhaps your presentation would be better served with a demonstration rather than slides.
  • Remember the adage “I hear, I forget. I see, I remember. I do, I understand.” Rather than telling a story or showing some slides, is there some kind of exercise you can make your audience participate in so that they will understand the ideas you’re trying to convey?

Plan with Pencil and Paper

Modern tools offer so many features and shiny buttons that it’s easy to get lost in their features and focus on the tools rather than the work you’re trying to create with the tools. It’s like being an astronomer who’s endlessly fascinated with telescopes; you forget that it’s about what’s in space.

The next time you have to make a presentation, don’t dive straight into PowerPoint. Instead, break out some paper and a pencil and use them to plan your presentation. Pencil and paper are so simple that there’s very little to distract you from the ideas you’re trying to convey. You’ll concentrate more on your presentation and less on the tools.

Break Away from Bullet Points

We’ve all suffered through presentations that are nothing but decks of slides that are simply bullet point lists. Bullet points turn slides into cue cards, and the are few presentation sins worse than reading bullet point slides to an audience. Stop doing that!

Bullet points are far better used for notes or to enhance the readability of an essay than on a slide. Putting bullet points in your speaker notes is fine, but take them off your slides. Rather than make a slide with bullet points, try making a slide for each bullet point instead, and try using a graphic rather than text for each “slide point”.

The Presentation Deck and the Take-Home Deck

“You’ve got to put bullet point lists on your slides,” I’ve been told many times, “otherwise the deck won’t make any sense to people reading it later!” I understand the reasoning behind this, but I don’t think that’s the solution.

Unfortunately, the best solution I can think of means more work. My approach is, where possible, to produce two versions of a deck:

  • The Presentation Version, which I use when making the presentation. It’s light on text and bullet point lists because I’m there, doing the actual presenting rather than letting the deck do it for me.
  • The Take-Home Version, which people can read later. It’s heavier on text and bullet point lists because I’m not there to do the presentation; in that situation, it’s just the reader and the deck.

Learn from These Resources

This article also appears in Canadian Developer Connection.


This Week on “Ignite Your Coding”: Uncle Bob!

uncle bob martin

Say “Uncle”!

This week on the Ignite Your Coding live webcast, we have a very special guest: Robert C. "Uncle Bob" Martin!

His business card may say “Robert C. Martin”, founder and CEO of the Object Mentor consulting firm, but we know and love him as “Uncle Bob”. He’s been coding since the Beatles broke up, and in that four-decade span, he literally wrote the books on agile and extreme programming as well as the letters UML, OOP and C++. Throughout the industry, he’s known as a champion of proper design, test-driven development and just plain writing good code. We’ll chat with Uncle Bob in this one-hour webcast, where we’ll talk about software craftsmanship, why it takes work and why it matters.

What’s Ignite Your Coding About?

Ignite Your Coding Ignite Your Coding is a webcast series all about helping you, the software developer. We want to help you find ways to stay on top of the technological, economic and social changes that affect you and your work every day. We contacted some of the biggest thinkers and doers in our field and asked them if they’d like to chat about the industry, how they got started, where they see the opportunities are, how they deal with change and how to be generally awesome. We hope it informs and inspires you!

How Do I Catch the Live Webcast?

You’ll need:

How Do I Get the MP3 Recording of the Webcast?

It’ll be posted on this blog in about a week.

This article also appears in Canadian Developer Connection.


So You Need a Typeface…

so you need a typeface flowchart

Got a project and can’t decide on a typeface? This chart is by no means complete, but it might help steer you in the right direction. Click it to see it at full size.

This article also appears in Canadian Developer Connection.


Toronto Code Camp: Saturday, May 1st!

Toronto Code Camp logoThe 5th annual Toronto Code Camp takes place next Saturday, May 1st, in the SEQ building on Seneca College’s York Campus (Seneca@York). If you’re a developer who builds or is thinking of building on the .NET platform, you want to catch this free event!

Last year’s event had over 350 attendees who caught 25 sessions, including the infamous “Data Bondage with Silverlight”, which opened with the equally infamous “assless chaps and accordion performance”. I make no guarantees this year, other than that I’ll be there and that this year’s event will be the biggest and best one yet, with a whopping 40 sessions arranged into 8 tracks.

Seneca@York campus at night

Code Camp happens because of Chris Dufour, .NET community guy extraordinare, who’s been making it happen for the past few years. It’s a free-as-in-beer event, a labour of love carried out by Chris and a team of dedicated volunteers and funded by generous sponsors including The Empire.

Here’s a run-down of Toronto Code Camp 2010’s agenda:

Time What’s Happening
8:30 a.m. – 9:00 a.m. Registration
9:00 a.m. – 9:30 a.m. Keynote
9:30 a.m. – 10:45 a.m. Sessions

10:45 a.m. – 11:00 a.m. Break
11:00 a.m. – 12:15 p.m. Sessions

12:15 p.m. – 1:30 p.m. Lunch
1:30 p.m. – 2:45 p.m. Sessions

2:45 p.m. – 3:00 p.m. Break
3:00 p.m. – 4:15 p.m. Sessions

4:15 p.m. – 4:30 p.m. Break
4:30 p.m. – 5:45 p,m. Sessions

5:45 p.m. – 6:00 p.m. Break
6:00 p.m. – 6:30 p.m. Closing
6:30 p.m. “The Hive” Afterparty
If you want to attend this event, please register!
Later After the afterparty, a tour of York University’s astronomy observatory!


I’ll be present at the event, making myself useful as an official Microsoft representative and as a Windows Phone 7 Champ and Azure go-to guy.

Toronto Code Camp takes place in the SEQ building at Seneca’s campus at York University, which is at 70 The Pond Road. Click the map below to see a Bing map and get directions:

Map to Toronto Code Camp (70 The Pond Road)

See you there!

This article also appears in Canadian Developer Connection.


Apple, Windows Phone 7 and Burning the Boats (or: Why I Think Windows Phone 7 Doesn’t Have Copy and Paste)

Replica Spanish galleon on fire

Sometimes, you have to do more than just start from scratch. Sometimes, you have to burn the boats.

“Burning the boats” is an expression that comes from a story – some say legend — about Cortes, the Spanish Conquistador (and yes, the subject of Neil Young’s Cortez the Killer). Wishing to guarantee that his men would stay in Veracruz (which he’d just taken over from the Governor of Cuba) and only move forward into terra incognita without retreat, he ordered them to burn the ships that brought them to the New World. It was an extreme measure, but without the distraction of a way home, they committed themselves completely to business of exploring and conquering.

The Original Mac: No Arrow Keys

Bruce “Tog” Tognazzini, former user interface guy at Apple and the company formerly known as Sun, and now member of the Nielsen/Norman Group, wrote about how Apple burned the boats back when they released the original Macintosh in his 1992 book Tog on Interface and more recently in an article on his blog, AskTog.

Original IBM PC and Apple // computers

In 1984, the Macintosh represented a break from the dominant paradigm at the time: the command-line interface. Back then, you’d issue commands to a program these ways:

  • Typing them in
  • Using control-key combinations
  • Using function keys
  • Using the arrow keys to navigate

Software developers at the time had little experience developing for GUIs, which meant that there would be great temptation for them to simply develop apps for the Mac the way they did for other platforms. The software they’d end up writing would be a command-line app that just happened to run on the Mac.

Steve Jobs and Apple’s Macintosh team, an unconventional bunch who were said to have nary a classical computer science degree among them, thought that existing software sucked. I was 16 at the time, and I’d have to agree. In order to prevent straight ports of existing software to the Mac, they decided to “burn the boats” and make it difficult for developers to “go home” and simply rely on the UI techniques from the Old World. The first Mac keyboards didn’t just omit the function keys, they also left out the arrow keys:

Original 128K Macintosh. "See? No arrow, function or control keys."

Tog writes:

That was a big deal. Almost every application then in existence depended on the arrow keys (then called cursor keys) for navigation. With that one stroke, Steve reduced the number of apps that could be easily ported to the Mac from tens of thousands to zero, ensuring that this new computer would have a long and painful childhood.

It’s counterintuitive to want to have your creation go through a long and painful childhood, but there was a method to their madness. In “burning the boats” by getting rid of the function and arrow keys on which developers relied and taking away their “way home”, they forced developers to redesign and rewrite their applications to fit a mouse-driven graphical interface rather than a keyboard-driven command-line interface.

They eventually brought back the arrow keys about a year and a half later. By that point, developers had grown used to developing GUI apps that took advantage of the UI controls and mouse that we’ve come to know and love. The return of the arrow keys at that point would now be a welcome addition and convenience, rather than a dangerous temptation to return to “the old ways”.

It was a bold move, but when you’re making radical changes to the way things are done, bold moves are often required.

Windows Phone 7: No Copy and Paste

Copy and Paste icons

There’s been some talk about Windows Phone 7’s lack of copy and paste. It’s similar to the hue and cry about the original iPhone’s lack of copy and paste, and having been reminded by Tog’s article about the design decisions made for the original Mac, I can see the method to Microsoft’s madness.

“Copy and paste already exists in Windows,” people have said, “why not Windows Phone 7?”

The answer is simple: because Windows Phone 7 apps aren’t supposed to be like Windows apps. For non-enterprise, non-industrial use, the “Windows, but scaled down” approach of previous versions of Windows for phones, which goes under the name Windows Mobile, didn’t catch on (Windows Mobile still rules the roost for compact devices used in enterprises and industries, and will be supported for years to come). Hence Albert Shum’s completely different-from-the-desktop, and even different-from-other-phones Windows Phone 7 interface, which went by the codename “Metro”.

Windows Phone 7 hubs: music+video, people, pictures, office, games

The use of copy and paste implies a keyboard-centric user interface, which isn’t what Windows Phone 7 is about. People often use their smartphones one-handed, with only their thumb to access the touchscreen. Windows Phone 7’s interface takes this usage into account, which is why it’s sensor-centric, and applications, should get their information from touch, gestures, accelerometers, location and other sensors where possible. By not including copy and paste in the first release, the Windows Phone team is “burning the boats” and asking developers “How do you write apps so that they don’t need intricate more-suited-to-the-desktop operations like copy and paste?”

(And yes, copy and paste will eventually find its way into Windows Phone 7, just as the arrow keys, function keys and even right-clicking found their way into the Mac.)

The same could be said for many other things that were purposely excluded from Windows Phone 7, such as the compact edition of SQL Server that was part of Windows Mobile. If you think about it, this design decision forces you to build apps so they store and retrieve data from the network, which makes sense, since phones are devices that network with both cellular and wifi.

Windows Phone 7 represents a radical shift in the way Microsoft stuff works, from a very minimalistic look to its task-centric organization. In order to make sure that people built apps that fit it, the Windows Phone 7 team had to burn the boats. It’s a bold move, but it’s the right one.


Talking to the Kids in Their Language


When I was young, I used to cringe when adults made clumsy, if well-intentioned, attempts to speak in what they thought was “youthful slang” in order to make a connection with us.

Now that I’m one of those adults, I can’t tell for sure whether the message in this poster (which I saw in the Toronto subway yesterday) comes across to today’s net/text-speaking youth as clever or clumsy. I’m torn – should my reaction be LOL or WTF?

(And is it me, or does the expression on the guy’s face say BRB?)

This article also appears in The Adventures of Accordion Guy in the 21st Century.


This Week on Ignite Your Coding: Jeff Atwood!

Joey deVilla interviewing Jeff Atwood at PDC 2008

Our guest on Ignite Your Coding this week, Jeff Atwood, has certainly made his mark in the programming world with the Coding Horror blog as well as his project with Joel Spolsky, the online developer forum Stack Overflow (which in turn gave rise to the Server Fault and SuperUser forums). Join me and John Bristowe this Thursday as we chat with Jeff about Coding Horror, Stack Overflow, software development, fake plastic rock, P=NP and whatever topics you, the listener, want covered.

We’ll be chatting with Jeff live this Thursday at 2:00 p.m. Eastern (11:00 a.m. Pacific) online.

What’s Ignite Your Coding About?

Ignite Your Coding Ignite Your Coding is a webcast series all about helping you, the software developer. We want to help you find ways to stay on top of the technological, economic and social changes that affect you and your work every day. We contacted some of the biggest thinkers and doers in our field and asked them if they’d like to chat about the industry, how they got started, where they see the opportunities are, how they deal with change and how to be generally awesome. We hope it informs and inspires you!

How Do I Catch the Live Webcast?

You’ll need:

How Do I Get the MP3 Recording of the Webcast?

It’ll be posted on this blog in about a week.

Who’s Coming Up on Ignite Your Coding?

This article also appears in Canadian Developer Connection.