Slide Driven Development

Begin with the end in mind.

I’m not sure which begat what in the gnarled tree of TDD, BDD, DDD, et al, but because there’s always room for one more rattlin’ branch:

SDD: Slide (Deck) Driven Development.¹

Expand the scope of outside-in design methodology to the kind of polished presentation your stakeholders and customers might enjoy – or at least tolerate – and you have something resembling SSD. You could call it SSDD, but where I’m from, that acronym means something else. Or you could just call it PDD or PPDD, but let’s at least try to be vendor-neutral.

…ugh.

Fair point.

I’ve seen plenty of terrible slide decks, and you probably have too, but I’ve seen many more that were compelling and entertaining. The decks that have impressed me the most have been created by and for people in tech, usually presented at community-oriented meetups and conferences.

Slide decks are useful across functional areas. They convey ideas effectively to leadership, product folks, designers, peers outside your company, and prospective customers. They can speak to your fellow engineers, too, as long as they illustrate an elegant architecture or process and inspire a sense of purpose in implementing it.

…and memes might help. Try to make things entertaining if you think your audience will be receptive, but the all-division or all-company meeting might not be the best venue for tech-insider jokes and crude jackassery. We’ll remember how you made us feel, so if you think anything could be remotely controversial, leave it out. Deprecate yourself if you want, but don’t be a jerk to, or about, anyone else.

Communicating with a slide deck is a skill you can build, and in my experience, the better you get at it, the more time you get to spend implementing your ideas. Spend some time on the dark side. They usually have donuts.

You’ll be glad you have it.

You might even enjoy creating the slide deck. I have, to my surprise, several times.

There are several benefits to starting the development process with a solid pitch. Thinking carefully about your vision and documenting it at the outset helps you:

• more deeply understand your idea by forcing yourself to simply explain it
• get sanction and priority from your team to implement your idea
• demo your work once you’re finished without retrofitting any documentation
• stay focused on the externally-observable behavior and outcomes of your work

how to do SDD™

Images are so much more interesting than text. You can search Unsplash for royalty-free high-quality images. Please credit the contributors!

Less is more.

Use a lot of whitespace. Let it breathe. Keep it legible for people squinting in the back of the room. Increase the font size. Increase it again.

We’re here to see and to listen, not to read.

When presenting, do not read from your slides. There shouldn’t be enough text on any slide for you to feel compelled to read it to us, and we’re already going to attempt to read the slide content on our own.

Be kind to us: give us images, simple diagrams, and maybe a few choice words.

Be careful with code.

If a slide includes a code sample, a concept is best demonstrated in about 10 lines of code or fewer. A (small) function or two is acceptable. A whole page of code isn’t, unless you’re presenting it to show the shape of the code. In that case, acknowledge that it’s illegible to most of your audience and disclaim the slide with “don’t try to read this.”

If it’s well-suited to a narrative as you walk through the code example, highlight/bold a different word or clause on each slide as you “walk” through the same block of code in subsequent slides.

Visually interesting, not distracting.

Don’t use looping videos on a slide where you’ll linger for a while and talk, because they quickly become annoying.

Absolutely no strobing.

Splitting up your ideas into more slides, at a faster pace, with less content per slide, will help keep your audience’s attention.

Keep it offline.

Check to make sure you can get through your entire deck with your wi-fi turned off. Presenting can be challenging enough without your deck or demo freezing because you never exported the final version from your online tool into an offline document.

further reading

Refer to Nina Zakharenko’s excellent Ultimate Guide to Memorable Tech Talks for similar (and many more) ideas and inspiration, far better expressed.

“We don’t pay you to draw pictures.”

This was a tongue-in-cheek joke on one of my former teams. What’s more accurate: they don’t pay you to write code. As an engineer, the more time you spend thinking about the code you write as a cost to be paid for delighting customers, the more effective you’ll be.

Communicate the outcomes of your work, first and foremost. Spend more time up front collecting your thoughts and conveying them effectively to others. Write code only incidentally, if you must, to deliver that delight… with as few lines and as little complexity as possible.