Writing software is hard, particularly when the schedules keep programmers “nose to the grindstone”; every so often, it's important to take a breather and look around the world and discover what we can find-ironically, what we find can often help us write software better.
What do giving software presentations and writing software have in common? Can one teach us about the other?
Ever had one of those days? The youngest kid's first band concert is tonight, the car needs new registration tabs (as the helpful officer pointed out last night during the “routine traffic stop”), and the magazine editor is calling because the column is late, despite voluminous trolls through the basket of ideas that all seemed great at the time they were captured, yet absolutely nothing wants to emerge from the fingers?
Yeah, me neither.
But if I were a desperate author scrabbling for a topic, a Twitter conversation between two well-recognized individuals within the industry might provide precisely the inspiration required. Particularly if it were, say, a discussion (or at least as much as 140 characters at a time can allow for a discussion, anyway) about speakers, slides, and doing what's “right” by the audience.
And it just SO happened that such a conversation happened to take place on Twitter recently, between CODE Magazine's fearless editor-in-chief Rod Paddock and well-respected agile coach and Open Spaces guru (and, I'm fortunate to say, good friend) Steven “Doc” List.
The Setup
Specifically, Doc wrote, “Presentation tip: know your material, and create it more than one day before you present. This lets you focus on the audience.” Rod added, “I agree 100%. There is no reason to do slide/demo tweaks at the last minute. It shows disrespect for the audience who expect preparation.”
Those who know me off-stage know already that I'm one who tends towards the last-minute tweak of slides, and they probably won't be surprised to hear that I replied, “Not so! Tweaking at the last minute != lack of preparation. Tweaking == I'm still thinking about how to do this right.”
(By the way, apologies in advance to the VB readers of this column for the use of the double-equals. I admit it, I think in C-family operators. Makes it hellish for my accountant, let me tell you.)
We went back and forth for a bit, a conversation that I will defer for now, because the rest of the conversation wasn't nearly as interesting as the thought process that fired off as a result.
Specifically, who's right?
The Premise
By his Tweet, Doc (and thousands of other presentation tip-offering books, websites, and gurus) suggests that a good presenter should have her material well-practiced and fluid long before the crowd appears. Rod agreed at one point: “Slides are outlines. The outline should be done long before.”
I suggest, however, that if the presentation is to be effective, one has to take the audience into account, which includes knowing the skill and interests of the audience, something that cannot be known until late-possibly not until I arrive at the conference and talk to the other presenters to find out their experiences thus far. (Believe me, no conference is ever as advanced or as basic as the organizers claim, and there are wild differences between crowds-some groups are passionate and eager, some groups are reserved, some groups are cynical, and some groups are just dead inside.)
Among presenters, both arguments are defensible. So who's right?
The Agile Take
Within the agile community, similar kinds of discussions have taken place, generally lumped under the global heading of “YAGNI”: You Aint Gonna Need It. It's a generalized reaction to the “Big Up-Front Design” that C++ developers had a tendency to advocate, in which we tried to create “reusable” designs and frameworks long before we even knew if they were usable. Building a framework before building the app had a disturbing tendency to mean that neither actually ever shipped. Trying to predict how people might use the framework in the future usually meant that the framework was wildly difficult to use for applications today.
In short, agile (voiced by Kent Beck as part of eXtreme Programming) suggested a contrary approach: that developers should “design for today” and when tomorrow kicks in, refactor the code to accommodate the change when it actually shows up. Flying entirely in the face of the “well-established” fact that “the cost of change explodes exponentially over time,” “design for today” relied on the above acronym to answer the challenge of “design for the future” by pointing out that at least half the time, the need for the things designed into the framework to accommodate change over time never actually materialized. In essence, all that complexity and all that time spent designing for the future was a waste of time.
In fact, this was the rationale behind the comprehensive suite of unit tests. If we accept that we can't predict the future accurately, and therefore have to accommodate the fact that “change happens” and therefore the code has to change with it, then we have to make sure that changes to the code base don't break everything when they do happen. Having a set of tests to ensure that all the tiny little bits of the code continue to do as they are supposed to do gives us that freedom. In essence, unit tests become the safety net that violently informs the developer when a refactoring takes the code down an unknown path-without unit tests, refactoring becomes a nigh-impossibility and too dangerous to seriously contemplate.
And over time, unit tests have proven themselves, when implemented with gusto, to provide exactly that kind of refactoring freedom. Buddies of mine from ThoughtWorks talk about making substantial core changes to an application the night before its public release with complete confidence, because the unit tests guaranteed that nothing has broken. When a test failed, the bug in the new code could be tracked down and squashed long before the users saw anything. One such refactoring included adding a second database to act as a sort of “horizontal partition” to the first, and users never knew the change had happened until the developers told them about it a few weeks later.
Over time, this desire to avoid YAGNI eventually turned into “agile means never thinking ahead of today,” which, although a predictable plunge to the opposite end of the spectrum, is a complete misrepresentation of what the agile community was trying to state. Agilists later came back to suggest that what agile really meant by YAGNI was that decisions should be deferred to “the last responsible moment”-which in some cases, meant well after the realization that “we might need this someday.”
Which brings us back to speakers and slides-when is the “last responsible moment” when it comes to slides and preparation for a talk? And if unit tests allow us to change code with confidence, what is the moral equivalent in presentations?
Suggested Conclusions
Unfortunately, not all stories have a happy ending, at least not in the “real world.” No “unit test framework” for slides presents itself, but at the same time, slides aren't compiled or executed. (The day Microsoft ships the PowerPoint compiler is the day they take over the industry, mostly because everybody else will flee in horror.) This means that the unit tests have to be somewhere further back in the process, deep within the presenter's mind.
I won't speak for all presenters, but I'd be willing to bet that most veteran presenters, even as they're changing up the order of their slides ten minutes before the talk begins, have a pretty strong idea of what they want to talk about. It's not a question of creating an outline, per se, but of rearranging the outline and considering leaves to that outline that might best match that audience's interests and skills. No responsible (or respectable) presenter would try to present an introduction to F# talk, for example, to an audience unfamiliar with functional concepts by tossing out the terms “monad” and “catamorphism,” yet those same terms and concepts would be entirely appropriate in an intro to F# talk at a functional programming conference. The veteran presenter isn't any less prepared to give the talk, even if they're writing slides just minutes before they show them, because they've already fleshed out the body of the talk in their heads weeks-or months, or years-before now.
Is this responsible? As with all things philosophical, it depends. A beginning presenter attempting this kind of nuance is likely to fall flat on his face, and so it's hard to recommend as a result. But to the veteran presenter, Doc puts it best: “No absolute rules.” and “Changing at last minute, or creating at last minute, is advanced practice. Shu-Ha-Ri.”
For beginning agilists, then, what is the takeaway? Well, it's going to be hard to give up making those decisions early-on. But without a comprehensive set of unit tests, don't even attempt it. The agilist needs to have those unit tests in place to be able to refactor with confidence-and without those unit tests, effective refactoring is all but impossible, meaning that the real benefit of unit tests don't appear until the end of the project. So think of investments into the unit tests suite as deposits into an account that allows the team to buy safe refactoring further and further away from today. Essentially, unit tests allow developers to “bank” responsibility, just as weeks of practicing demos and thinking about slides “bank” the presenter's ability to adjust slides and demos at the last moment.
Meanwhile, I'll have to remember to check Twitter for topics more often.
(For those interested in helping out authors who find themselves periodically struggling for inspiration for a column remarkably similar to this one, I suggest they send Tweets with questions, comments or thoughts to @tedneward. Not that I'm periodically struggling for inspiration, mind you. Of course not.)
