Appirio organized a contest to explain in a video presentation what cloud computing is about.
The result were a lot of amazing videos from boring lengthy explanations that would even would bore a nerd out of if skull, to very short to the point.
The one that won the contest was the cloud computing rap song: funny and in less than two minutes
Everybody has heard the controversial stories of gurus creating successful enterprises based on a business model written on the back of napkin.
I always have been a believer in simplified visual models to explain complex things: “One picture says more than a thousand words” but Dan Roam has taken this idea a step further and created a complete theory and methodology around it.
I recently bumped into his book “The Back of the Napkin: Solving Problems and Selling Ideas with Pictures” but it has been around some time. The book was published in 2008.
Below you?l find some of mine personal highlights.
Where is the picture?
One of the things Dan says, if you ask young children, in the first year of a primary school, if they can draw a picture they all will raise their hands. If you ask them who can read or write some might hesitatingly raise their hand.
Ask the same question to adults you?l get a reversed answer. Does it mean we all lost the capability of drawing when getting older? No, off course is doesn’t. It only stresses that a lot of people are reluctant to make visual representations of their ideas. However it shows that who’s capable of representing complex problems visually has an advantage because we all know that one picture says more a thousand words.
According to Dan whoever describes the problem the best is most likely to solve the problem. It boils down to: whoever is capable of making enough abstracting of a problem based on insight, so the core of the problem can be presented in a simple way, is more likely to find a solution to it. In business terms this might mean Who will get the contract. If you are expert drawings can help you to get your message across to a audience with lower expertise.
Dan takes this idea a step further. Based on visual modeling techniques you can become the expert because the drawings can help you create insight in a complex problem.
Dead by PowerPoint!
Presenting a very complex diagram, with all of its details, at once will result in a blockage in your audience. It is better to build up the diagram step by step and may-be leave some details out. Diagrams should be limited to boxes, triangles, circles, arrows and stick figures. Using these should be sufficient to get any message across. Making it more detailed than this, you?l risk losing your audience.
The more human the picture the more human the response!
If you want any interaction and feedback don’t present results that look too finished. Smooth and clean slides do not look like a work in progress so the involved parties might think that already everything has been decided and the presentation is just a formal requirement to convince them. If you present something coarser material your audience will be much happier to jump in and reason with you in order to help you to create a finished result.
Who owns the whiteboard?
“You’ll have black-pen people, yellow-pen people and red-pen people when you’ve meeting in front of a whiteboard” explains Dan.
The black-pen people are the ones that think visually and what to start drawing to understand the problem. They are very eager to run to the whiteboard but do not necessary understand the problem.
The yellow-pen people have some understanding of the problem but are not that visually oriented. So the like to highlight, hence yellow-pen, some parts where they can add their input.
The red-pen people are the experts. They find that the problem is drawn over-simplified and under these conditions they don’t want to give their input. These are the one that get fed up in the middle of the meeting and start correcting, hence red-pen, the diagram. The idea is to get them fed up so they start giving their input.
Why some like words instead of drawings?
The idea of diagrams is that get the message across in an unambiguous way. So drawings are very useful if you want to be sure that everybody got the idea even across cultural and language boundaries.
If the goal is not to clear up the confusion but to put across a more political message you can understand why some people would like to avoid creating crisp and clear diagrams about what they are saying.
What is Visual Processing? This is the cognitive process behind visual thinking. According to Dan our visual thinking has six core activities or parts:
What: indentifying the objects, the things.
Quantities: how much of the things.
Where: physical relationship between the things.
When: physical change in the where of the what, the passage of time.
How: cause-effect model what, where and when.
Why: deducing how the world works, relationships between how, what, where and when.
Conclusion
I still need to read the book. But I think the ideas behind it are quiet solid. They at least feel natural to me. I have had in my professional life the same kind of experiences. Falling back on a whiteboard because the slick presentation, with overly complex diagrams, wasn’t getting any attention.
A few months ago I got a request from the owner of a small business to help out in porting a legacy application to a .Net WinForms. I thought that it probably would be some old VB6 code or ASP page that needed a new look and the conversion would be pretty straightforward.
To my amazement I was confronted with an old Clipper application running against a dBASE III database on MS DOS 6.1. I have seen a lot of legacy so I’m not easy startled, but this was going back to the eighties and my first encounters with a computer.
The owner underlined that is was a business critical application and that he thought it was about time to invest in some newer technology. It appeared to be an application responsible for resource planning i.e. assigning technicians to appointments with clients.
My first response was to have a look at cheap CRM or basic planning-and-calendar software. But I couldn? convince him. He was so used to working with his old software: “It provided everything that he needed!”.
So my quest started:
Is there a dBASE version that runs on Windows Server 2003?
Are there any drivers capable of reading dBASE III *.dbf files?
Are there any conversion tools for Clipper source code?
Apparently the Clipper community is still alive and kicking. Clipper, created in 1985, was embraced by CA and in 2002 they released CA-Clipper. Digging further I also found an open source project called Harbour supporting Clipper but in the end Vulcan.NET saved my day.
Vulcan .NET integrates with Visual Studio as any other .Net language and is fully CLS compliant. (To get started have a look at Vulcan.NET At Warp Speed Guide)
About eighty percent of the legacy Clipper PRG files, I imported directly without any problems. So a lot off the ‘business logic’ was saved and compiled into a separate managed DLL.
The old database tables were accessible through the VulcanDB database driver. Without any major glitches the content was recovered.
Writing the front-end was reduced to choosing any modern .NET technology. In my case, just adding some ASP. Net pages that call the converted clipper methods.
With minimal effort a lot off the existing code and content was recovered in a fresh .NET environment. Although the project was terminated here, I would personally have gone the extra mile by converting the database to SQL Server and by rewriting the Clipper code into some more wide-spread language (C# for example).
Since the owner was happy, I’m happy but I think an of-the-shelve package would have saved him a lot of money.
When talking about components people use the same word for different levels of granularity making it very confusing. Is one object considered to be a component? Is a class library a component?
Is a component the boundary between intra-component synchronous and inter-component asynchronous communication?
Pat Helland created an overview using the Three Bears analogy: Baby-Bear, Momma-Bear and Papa-Bear. Below you see a summary but you can always visit his weblog for details.
It is just funny and because of that, developers will remember during discussion about components to ask themselves at what level of component granularity the discussion is going on.
Summary:
Baby-Bears are much like the classic object with inheritance, reference-passing, and synchronous interactions with their callers.
Momma-Bears (closely related to what is provided by MEF), are comprised of multiple Baby-Bears. While exhibiting synchronous call patterns, they do not support pass-by-reference nor inheritance. They will, however, allow for support of dependency injection.
Papa-Bears are the biggest of the three and are most similar to a SOA Service. A Papa-Bear will typically be composed of multiple Momma-Bears. Papa-Bears interact with their partners asynchronously, are frequently remote, do not support pass-by-reference or inheritance, and may be offline.
