AnecdotalEvidence, AppealToAuthority, AtomFeeds, BookCode, Broken, CodeExamples, ComparativeValues, DotVoting, DuplexBook, ExtemporarySpeaking, Flooded, JohnVlissides, LimitationsOfGeneralAdvice, MoreVersionControl, MotionGraphics, MovingAwayFromXslt, MultipleDesktops, Neologism, NetNastiness, PedestalPhobia, QuestionTimePanel, RssFeeds, SemanticDiffusion, SignatureSeriesCriteria, StandardsSpeak, SuiteOfTalks, TalkNotes, Translations, UnforgivenContract, VisualChannel, WhatIsaBliki, WikipediaDeath, iPad
||6 December 2010
At the end of the 1990's I made a personal push-back against
using slides in presentations, as I was tired by poorly designed
bullet-points presentations. For around a decade, I gave keynotes
with no slides at all. In the last year or so I've started using
slides again - primarily inspired by watching my colleague Neal Ford who turns the dreaded
slide-deck into a genuine enhancement to his talks (and is
collaborating on a book
project to pass on his techniques). As I've been working with
slides again, I've also been thinking about what makes a set of
slides an effective part of a talk. Thee main principle I've tried
to follow is to think of them as a visual channel that complements
the audio channel which is my spoken words. I find that thinking
them of separate channels in this way helps me avoid common problems
with presentations - many of which are rooted in the commonplace
bullet point slides.
Most presentation mavens will tell you to avoid bullet point
slides, but that leaves the question of what should should go
there. When I think of a complimentary visual channel, it makes me
think of what visual elements will match my words. This means
that the visual channel needs to make the same point, but in a
Saying the same thing differently implies getting away from words
on the slide - or at least words that take much attention to read. That's one reason why bullet point sentences are out. But
I find words can work, providing they are just words not sentences.
The common approach these days for post-bullet-point
presentations is to use photographs. I've derided this by saying
that stock photos are the bullet points of the 21st
century. By this I don't mean that photos are always wrong, but
they often seem to be very unconnected with the speaker's words. I
get the impression of many hours spent crawling the internet for
some photo that tenuously goes with the talk. (And please, if you
use photos, make sure you credit the photographer.)
What I tend to use most is simple diagrams. I try to find some
arrangement of simple graphics (and words) that through their visual
positioning can help to illustrate, and thus better explain, my words.
Here's a somewhat random example that I picked from my Essence of
At this point in the talk I'm describing the plan-driven approach
to software that the creators of agile were pushing back
against. My actual words that go with slide vary depending on the day
I give the talk, but they hit these points:
(In a plan driven world)
- The software development activity depends on having stable requirements
- Most of the time, the stability of requirements is questionable
- The plan-driven community knows that requirements stability is
hard so explicitly seeks to stabilize them
- Stabilization techniques include up-front
requirements, change control boards, and sign-offs
In my talking, I don't verbally state the techniques, instead
leaving that list for the slide to illustrate. I think a list of
examples is best left to the visual channel.
I've shown this slide as a single graphic, but when I give the
talk the slide builds up over a sequence of slides and builds, with
me timing the builds to match what I'm saying. This is an example of
another aspect of my approach to the visual channel - using
motion. Of course it's not uncommon for people to use animations on
slides, but too often these animations are gratuitous sizzle that
are there purely to show off the capabilities of the presentation
software. I've no problem in using sizzle, but I try to always match
an animation to what I'm saying, so that the animation can be part
of that semantically rich visual channel.
An example here is what I do with the slide after this one. That
slide is very similar to this one, just showing an earlier point in
the build sequence (the point of software development depending on
requirements stability). Most of the time I just use a simple fade
to transition from one slide to another, but in this case I'm
starting to discuss the agile approach to dealing with this
dependency. As a result I do a fancy 3D cube rotation animation, to
illustrate the point that we are changing perspectives into the
agile world-view. Whenever I switch between the plan-driven and
agile world-views in the talk, I do a 3D cube rotate. That
transition is eye-candy, but when used this way I think it's
eye-candy that helps communicate the point I'm making.
I think that since we have animation available to us when doing
presentations, we should use it to enhance the visual channel,
providing I can do this in a way that fulfills the role of the
visual channel. That role is to keep the eyes engaged in an activity
that supports my words without distracting from them.
||29 November 2010
As I've been using slides again as a visual channel in my talks,
I've been making use of animation with diagrams to help communicate
my points. The major presentation programs (Keynote and Powerpoint)
have long supported animation, but I've been inclinded to look for
motion grahics tools that are more powerful and easier to use.
The two main ones that come up in my searching are Adobe's After
Effects and Apple's Motion. Both tools are very capabable, but also
very expensive: effectively costing about $1000. I got hold of a
trial version of After Effects which was a good way to get a feel
for it. Infuriatingly I can't do the same with Motion since Apple don't
provide trial versions of their software.
One of the directions I was interested in persuing was making use
of 3 dimensions. This led me to experiment with Blender, which is a
open-source 3D modeling and animation tool. I ran into two main
problems, which made it much slower to work with than After
Effects. Firstly thinking in 3D is more difficult, and I'm not sure
the results are usually worth the extra effort involved. Secondly
the UI for blender is very idiosyncratic, which made it
frustratingly difficult to do even simple things.
One of the frustrations for me here is that all the tools I've
been looking at so far do lots of things that I'm not so interested in,
which makes it harder to use them for my main purpose.
||4 June 2010
I've not seen myself as an iFanboy. I didn't get an iPhone for
ages after it came out, and only got one because it was the only way
to upgrade my data plan to 3G. I use a mac, but I also have an
Ubuntu desktop. But I have got an iPad, and I think it's a
I knew I wanted one right from the announcement. A while ago I
used my desktop for work and kept my laptop floating about the
house. I liked that arrangement as it allowed me to get away from my
desk for reading the web and doing email. But now that I use
Keynote, Aperture, and Omnigraffle I need to use my Mac with a big
screen. So my laptop is stuck on my desktop while I'm at home. To
compensate I bought a cheap laptop. But using a laptop like this was always
kludgy. The clam shell is awkward when I'm reading rather than
typing. The low battery life means I try to keep plugged in as
much as I can. So a few weeks ago I splashed out.
- The form factor and low weight makes it comfortable to use
on a sofa.
- There's enough battery life that I can forget about it as
long as I charge it overnight.
- The screen is gorgeous: bright, clear and sharp.
- The touch UI is familiar (due to the iPhone) and works
really well on a tablet device.
- Reading books using the Kindle app works really well. I
don't miss having a paper book and I appreciate the lighter
- Web surfing is mostly very good. I find myself using the
news apps from BBC, New York Times and NPR a lot.
- It's good for watching a movie. (The Netflix app could be
really big here, although I haven't used it yet.) I appreciated
the mix of reading and movie watching while flying back and
forth to San Francisco in a middle seat; not to mention the fact
that I used less than half my battery in the process.
- I worry about the lock-in when buying an electronic book. So
far I'm thinking Amazon is less likely to lock me into a
specific platform than iBooks. But I do worry that I'll have
lots of books that I can't read any more some day.
- Web-app sites, such as Google's, often don't work too
well. For regular use they make good use of the difference
between hover and click - and this doesn't work with the
iPad. This pushed me to get an app for reading my news feeds,
even though I like Google Reader.
- Like with my Android phone and the iPhone, it's awkward to
sync some text or html files from my other computers to my
iPad. This is annoying as I like sharing information this
way. Dropbox may be the answer, we'll see.
- Hotels with restrictive wifi are a real pain. I want to work
on my laptop with wifi and use that nice Netflix app on my
iPad. Paying for wifi is bad enough, being unable to use it on
multiple devices is awful.
- While it's ok to look at my inbox, the mail app doesn't work
well for threaded discussions on mailing lists.
- I would really like to be able to change the font size in
the web browser.
- Apple gets a lot of heat for being a curated software
system, rather than the traditional open one. Given how much of
my life I've lost to sorting out software incompatibilities I'm
not sure whether to like curation of not. In any case the
competition with Android and the like will prove
The Bottom Line
After a few hours with the iPad, I realized that I was feeling
a sensation I'd only remembered once before: back in 1995 when
someone showed me the World Wide Web. There's no dramatic new
technology, we've seen tablets before just as we'd seen hypertext
before. But the overall package was game-changer. I don't know if
the iPad will be The Device, but I do think that this kind of
device will make huge difference to how we read and watch things
in the future. I certainly need to work at making sure what I
produce in the future is built with these kinds of devices in
||5 June 2009
One of the most striking things about the Manifesto for Agile
Software Development is the format of its values "we favor x
over y". I don't remember who came up with that idea, or
how it arose. It probably just bubbled up as we tossed around ideas.
But it's distinctive format has led a few people to try using that
If you fancy trying this form, there's a couple of things to
remember about it, things that people don't always realize. The most
important of these is that the unfavored values are valuable
too. A phrase like "solving world hunger over slavery" doesn't
carry much power because hardly anyone is openly in favor of
slavery. The format works when both left and right sides of the
"over" are valuable things that most people want. What the
comparative values then say is that we want both things, but if push
comes to shove we prefer the one on the left. The harder choice
there is between right and left, the better the value statement.
So a good mental test is to imagine someone reversing each value
statement, indeed reversing all that you have in the set. There
should be people that you can imagine proudly and reasonably
supporting that opposite position. In our case we saw much of the
industry heading towards high-ceremony processes - reversing the
values we felt fairly summed up the values of that community. I can
easily imagine writing an article extolling why the reverse set of
values are a coherent world-view for software development by putting
myself into that mind-set.
The right-hand values may be the current state of the world you
want to change, or they may be a future state desired by another
community. Either way the comparative values are there to highlight
the contrast between one and the other.
Another point about the manifesto that I like is its brevity:
four comparative values and twelve principles. It's hard to get that
kind of brevity, but the briefer you make it - the punchier it
is. I'm sure the manifesto would have not had the impact it did if it had
forty-six value statements.
I'm one of those who has used this format since. Done well it can
really highlight what makes a particular philosophy different to
another. Here is another sample, a set of values I wrote to describe
how I saw ThoughtWorks as being different from other software
- Leveraging bright people over Making the most of
- Flexible career paths over Well-defined
- Delivering business value over Leading edge
- Learning new technologies over Mastering established
- Solving difficult problems over Increasing market
- Learning from mistakes over Avoidance of taking
- Delivery to the client over Quarterly results
We've since replaced this list with another
set of principles which try to capture how we want to be. But we
did use the comparative values for a while to try to explain both to
ourselves and others what made our aspirations different.
As such I think that not just is this format a good way to sum up
a world view, when done well it also leads to sharp discussions
about what people really want to care about. This usefulness comes
directly from the fact that you are making hard choices between
things that are all desirable.
||4 December 2007
I don't not write much production code these days, but I still
spend quite a few hours writing code. This code is a particular
form of code, meant for explaining ideas in books. Book code isn't
quite like real code, there are some different forces to consider
when writing it.
One question is the choice of language. I need to write code in a
language that as many of my readers can read and follow. I try to
write about ideas that are platform independent, but I need code to
be precise. So I need to pick some widely readable language that
people can follow.
In my early days the two largest OO languages were Smalltalk and
C++. Both had faults, Smalltalk was too weird for non-smalltalkers
and C++ was too full of sharp edges to get right. Java was a godsend
for me. Anyone with a C/C++ background could read it. Even most
smalltalkers could hold their noses and understand what I was
coding. That's why the refactoring book was in Java.
Later on .NET appeared. The nice thing here was the C# was mostly
the same as Java, so I could use the two pretty interchangeably. I
liked to use both to reinforce that the ideas I was writing about
were useful in either case.
That situation is getting more difficult these days, particularly
with writing about DomainSpecificLanguages. Java and C#
are diverging, and some things I want to illustrate require features
that neither of them have. I do much of my personal programming in
Ruby, which is very well suited to DSLs, so I will use Ruby as my
first choice for this situation. But other languages have
contributions too. I need to balance illustrating various language
capabilities for DSLs against letting the book become a hodgepodge
of language tidbits.
Another issue with book code is to beware of using obscure
features of the language, where obscure means for my general reader
rather than even someone fluent in the language I'm using. A good
example of this is that when I write examples using Ruby, I've often
shied away from using CollectionClosureMethods, even
though I use them heavily in my own Ruby code. This is because I
consider that programmers from a curly-brace background will find it
harder to understand those kinds of expressions. So I sacrifice
fluent Ruby in order to reach those readers.
Again this is much harder for a DSL book. Internal DSLs tend to
rely on abusing the native syntax in order to get readability. Much
of this abuse involves quirky corners of the language. Again I have
to balance showing readable DSL code against wallowing in quirk.
||13 June 2007
Last week I got the newest book in my signature series: xUnit Test
Patterns by Gerard Meszaros. I've been working with Gerard with it
on and off for a couple of years, so I'm fairly familiar with its
contents, but somehow seeing the physical copy gave me quite a
shock. Somehow it hadn't dawned on me how big the book was - 883
pages, easily the biggest book in my series.
On the whole I'm not keen on big books, I was very proud of
keeping UML Distilled so small. A book this big scares me, how will
I ever get time to read it?
But xUnit Test Patters isn't as scary as it looks, because it's
actually two books in one set of covers. In this it follows a style
I also used in P of
EAA. The first book is a narrative book, designed to be read
"cover to cover". The narrative book is something small enough to be
digestible, in xUnit Test Patterns it's 181 pages, 106 in P of
EAA. The second book is reference material, which is designed not be
be read cover to cover (although some people do) but instead to be
dipped into when needed. The idea is that you read the narrative
book to get a good understanding of the field, then put it on your
shelf so it's handy to grab when you need to delve into the
I read a lot of history books and I've often wished that the
author had written a duplex book. History books often need detail to
expand upon a particular topic or to describe the evidence for a
point of view. The result, however can be a long book. One example
is a favorite book of mine: Guns, Germs and Steel. I'm really glad I
read it, and I do recommend it. But it did feel long, and I wonder
how it would have worked in duplex.
How to Read a Book suggests that
when you read a book for the first time you should deliberately
skip-read it, unhesitatingly skipping over detail sections. I read
very fast, which helps me, but although fast or skip reading is a
plus, I'd rather the book was designed to help. My personal rule of
thumb is that 200 pages is the limit for a narrative cover-to-cover
technical book. If it goes over that you need some way to allow people to get
the core information with less bulk. A duplex book isn't the only way
to it, such as selected bolded paragraphs in the Timeless Way of Building, which worked pretty
well for me. I'm sure there are other techniques that I haven't run
into yet, but the duplex is currently top of my list.
A duplex book is really a specific case of a more general
principle to organize a book in gradually increasing sections. The
Pick Axe is a good example of this. The
first two chapters are a quick overview of ruby in 24 pages. Then you
have 280 pages of tutorial, followed by 500 odd pages of reference
material. The first few chapters of the Enterprise Integration
Patterns book is an overview (95 pages) with rest (~550 pages)
reference. Books like this often don't make these successive layers of
revelation as clear as they might, however.
An interesting question is whether we can do more with the duplex
book format. A lot people won't realize that xUnit Test Patterns is
a duplex book because it looks like one thick book (the back cover
actually claims it's three books by considering the reference section
as two separate sections). Could we physically split the books,
perhaps by packaging them as two volumes in a slip case? I don't
think actually selling the books separately would make sense as they
are too closely coupled together.
Naturally we think about online access. Reference material often
works better on the web, so perhaps we could make the reference book
web only (maybe with a CD or something in the physical book) and
sell only the narrative book. What would that structure do to sales?
There's interesting questions here, but the final message is that
I'd urge authors of big books to think more about how the book is
structured in a way that helps someone who wants something within
that 200 page limit.