How we prepare for a pitch or for any presentation...

Most of the ideas die at the pitch. That’s why it is so important to know how to do it the best way possible. If you have an idea worth spreading, you better be prepared to do a great presentation.

In the last few months my team and I were working on a new idea. After 6 weeks we needed to pitch the idea. If the idea was to flourish and survive, it was better to be prepared.

Learn from the greats.

Before preparing for any presentation I watch and rewrite my notes from Garr Reynold’s presentation at google. Garr is the author of presentation zen and presentation zen design. If you follow his advices you are closer to get a great presentation. So instead of doing a bad job writing of his teaching, I have embed the video here - bookmark now!




Always two there are: a master, and an apprentice

When I mention learning from great presenters, Garr  Reynolds and Nancy Duarte, comes to mind. But as any craft, art, science or anything worth teaching, there are always two: a master, and an apprentice. Garr and Nancy were once apprentice as well.

Nancy has done some great work analysing and studying the structure of great presentations. We used Nancy’s teaching to shape our pitch into, what I believe was,  one of the best presentation I have given.

"What it is" versus "What it could be" - the shape of a great presentation

Nancy has discovered the presentation form that great presenters have, to convey their messages, their Idea, their passion. In the following presentation at TED she shows the structure by analysing two great presentations: Rev. Dr. Martin Luther King Jr.’s speech from the March on Washington and the presentation of the IPhone by Steve Jobs. One more time instead of doing a bad job describing her teaching, here is the video of her presentation:


Nancy Duarte's talk at TEDx East from Duarte Design on Vimeo.

A Call to Action - How we used the presentation form?

Back to our pitch. When we were rehearsing for our presentation,  we drew a line to keep track of our time, but little did we know how helpful it was meant to be. We started analyzing the presentation shape. When we saw that the shape was flat for too long,  we change our presentation to follow the presentation structure discovered and described by Nancy. Every “"What is"  was followed by a "What could be”, a surprise, a better possible future, a problem to be eliminated or a great feature from our idea.

But the best advice from Nancy it’s how to end a presentation, a call to Action. A call to Action by describing how the world could be when you and the audience join forces and solved the big problem. Because the hero is not the presenter, the hero is the audience. Because without them, without their help, without their support all the ideas die.

Google Tech talks: Don't Make me click Notes  

By Aza Raskin - Head of User Experience for Mozilla Labs

Notes from the talk:

• Whats the best interface?   BLANK - NFI No F*** Interface
• Don't fall into the trap of look fancy/sexy/cool ( Adding interactions )
• Example splash screens on websites.
• Use Icons when text will do the work.
• What Google be if they advertise everything the search box can do.
• Its not about adding its about removing Interactions
• No RIA but ZIA - Zen Internet Application
• Act without doing  -> Pagination you have to interact continues listing
• Don’t force users to ask for more content -> just give it to them
• No by giving search result but by giving the thing you are looking for
• Zoom In Zoom Out  - to remove Interactions.
• People don’t think in forms. There are better ways:
• Good example: Quick Add box google calendar.
• Natural Lenguages Interfaces

the fewer keys you have to hit to get the computer to understand what you want, the less wasted effort, the more efficient the interface.

Are you ready to delete your code? Rocky Mountain Ruby 2011 Keynote - Code Blindness by Michael Feathers

Rocky Mountain Ruby 2011 Keynote - Michael Feathers

Rocky Mountain Ruby 2011 Keynote - Michael Feathers talks about the levels of code blindness - How much do we know about our code base, and what we do about it. He describe the following levels:

=> Total Ignorance - No control at all.

=> Metric Targeted - "You need X coverage, X PMD level etc" - The trap on this level is missing the context and just do it for the metric without understanding the spirit of the rules ( yes I've seen Methods split in half to remove Complexity warnings )

=> Qualitative Assesing - Not just metrics, but qualitative meaning in the metrics. From the junior programer to upper management, everyone understand what "Cyclomatic complexity" means, everyone understand the asset that they have.

=> Lifecycle Management - Code has a lifecycle. We must prepare to let go and delete the code/features/applications out of our repository. Planing for replacing. Say good bye to the old so the new can born.

=> Integrated Knowing - Entire Company knows what they have.....The code is a reflection of the Organisation - Conway's Law. What our code is saying about or Organisation?


Are you ready to let go our code? What your code is saying about your company? Realy interesting keynote

It is a Process...

When you sit down and solve a problem, that solution is merely a first draft.
—STOYAN STEFANOV, JAVASCRIPT PATTERNS



Got it from this great presentation:

http://www.slideshare.net/rmurphey/cleaner-leaner-meaner-refactoring-your-jquery

Javadoc - the “Why” of your code.

Code should not need to be figured out, it should be just read. -Martin Fowler

How do you express a not thread safe method? That null is not a valid parameter? That if you call a method in an object, the object will be in a different state? How do you communicate ownership of parameters?

In Java, some of these points are handle trough meta-data using annotations, throwing Exceptions, etc. Nevertheless there is a limit on how well it communicate intent, There is still a gap between the “How” and the “Why” of your code. For example you can declare the exceptions thrown by a method, but you can not fully communicate the why without the documentation, without the javadoc.

Java have limitations to communicate in code all that there is to say about the behavior of the program. Different languages, like Eiffel, provide more mechanism where you can define pre conditions, post conditions and invariants on the objects with the code itself. In Clojure the data structures are value object therefore there is no need to define the ownership of parameters you will always get something new. But even in those languages, there is a need to document - to express the "why" of your code, the reason behind your design, examples on how to use it or how to extend the code.

Joshua Bloch in "How to Design a Good API & Why it Matters" mention his rules about documentation which I use as guide lines:

Document Religiously

• Document every class, interface, method, constructor, parameter, and exception.
• Class: what an instance represents.
• Method: contract between method and its client.
• Preconditions, postconditions, side-effects.
• Parameter: indicate units, form, ownership.
• Document state space very carefully

Even when programming by intention or with languages that communicate better we still need documentation. Without the extra information provided by documentation future programmers have to guess about the missing documented behavior, ghosts side effects. That's why I encourage good documentation among my peers programmers.

"Reuse is something that is far easier to say than to do. Doing it requires both good design and very good documentation. Even when we see good design, which is still infrequently, we won't see the components reused without good documentation."
- D. L. Parnas, _Software Aging. Proceedings
of 16th International Conference Software
Engineering, 1994

The Agile Samurai Quote

"when reality messes with your plan, you change your plan—not reality. "

- Jonathan Rasmusson

"If art interprets our dreams, the computer executes them in the guise of programs! "
-Alan J. Perlis