In 2002 Ben Bernanke, in his capacity as a member of the Board of Governors of the Federal Reserve System, gave a speech to the United States Congress on the subject of tackling deflation. In it, he referenced Milton Friedman’s idea of using a metaphorical helicopter money-drop to ease deflationary pressures on an economy. Although the speech was cheered by proponents of loose monetary policy, the use of the helicopter metaphor was also seized upon by his detractors who soon labelled him “Helicopter Ben”. What is rather ironic about this label is that the ideas presented in Mr. Bernanke‘s speech were neither new nor unique; after all the helicopter drop analogy is actually attributed to Friedman, and most followers of neo-classical economics recognise the use of loose monetary policy as an economic tool. So a valid question is why Mr. Bernanke was deemed particularly deserving of the “Helicopter Ben” moniker? After all its not like anyone thought to label Friedman “Helicopter Milton”. From this author’s perspective, the key may lie in examining the context and contents of the speech. Its uniqueness is not in the ideas presented, but rather the wholly accessible manner in which they are presented. It was simple enough for the lay to understand the relevance of the underlying theories involved, despite the fact that there was no explicit mention of said theories. Put differently, he managed to successfully impart a message without recourse to complex terminology or language that may well have been lost in translation. Many walked away from the speech with a basic understanding of a complex tool of monetary policy. This also proved to be a double-edged sword, as it lowered the barrier for commentary and criticism; especially given the greater transmittance of information made possible by modern media. As a techno geek, who often struggles to explain complex subjects to less technical audiences, I marvelled at Bernanke‘s use of simple language and metaphor to convey what is undoubtedly a complex theory. However, I am also amply aware of the downsides! Getting a technical message across often feels like dancing precariously on a razor-thin wire, on the opposite end of which lies a satisfied and comfortable audience; but on either side of which lie two equally unpleasant outcomes. On the one side, the explanation becomes so simple that it leads to charges of condescension. And, on the other, the very real possibility of becoming bogged down with trivialities. After all the more accessible the concepts of a solution are, the more open it is to criticism whether constructive or not. I was once privy to a conversation where a young developer was trying to explain that most security policies are vulnerable to psychological attack. The reason he was trying to do so was to convince the client that there was a point of diminishing returns where designing security restrictions are concerned. Rather than the desired effect though, we ended up implementing the most complex (and yet still vulnerable) authorization mechanism I have ever come across. This junior developer had clearly danced so energetically that he fell off the wire taking the rest of us with him. All said and done, the rewards and satisfaction gained from pulling off this precarious dance can often be well worth the bother. Getting it right or wrong can make the difference between becoming the “go to” techie whose input is coveted, or the guy who is best kept away from non-technical colleagues. On many occasions, I have watched the eyes of presentation audiences glaze over when bombarded with technical concepts. In some cases the presenters tried to reconnect with their audience by explaining even more and encouraging the audience to ask questions. But these explanations often only introduced new concepts that the audience had hitherto not bothered to worry about. The result of which was that lost audiences got even more lost and the presenters even more desperate or frustrated. Worse still, not every audience actually indicates that they are lost. In some cases people sit quietly through a presentation and walk out at the end not having taken anything with them. Is there a key to success where communicating technical concepts is concerned? Evidently, keeping things simple and focused always helps. But it is also important to know your audience and try to gauge the impact of what you are saying. Every audience should have the key facts and understand the risks and benefits in any solution, preferably couched in language that they cannot understand. However, the use of said language should be dictated by the audience so as to avoid trivial distractions. Software Development