Google Plus: The Good and the Bad

I’m on Google+ and I’ve mostly found it pretty decent in the ~2.5 weeks I’ve been using it. (Also had an opportunity to do dogfood before it went live, but really, it’s a different world once it’s out there and being used for real, so that’s what this post is about.)

Thought I’d sum up my experiences to date. You’ll notice a lot of my comments compare it to Twitter, because after all the crowd has been similar so far. And honestly, I often find myself with something to write and having to decide whether to stick it on T, G, or both. The decision feels kind of arbitrary right now and will probably shift to G over time, unless Twitter gets its innovation seriously on …

The Good

Things to like about Google Plus …

  • The UI! I’ll call out the design first because it’s not been Google’s strong point in recent years. Yes, clean white pages were a breath of fresh air in 1997, but getting long in the tooth now, and Google Plus shows Google’s now getting serious about visual design, and beyond just statistical hue calibration.
  • Engagement. The overall experience leads to much higher engagement than I’ve seen with blogging, twitter, or anything else. For the big guys, you see literally dozens of comments in the first few minutes.
  • No size limit. You don’t have Twitter’s 140 character limit. Fortunately, Twitter taught us the benefits of brevity, so it’s very acceptable to write just a sentence or two. But you can still go all out with an entire paragraph and that’s fine too. And no more shoehorning txt,just 2fit the arbtrary char limit.
  • Comments. Compared to Twitter, I actually have all responses to my status in one place. On Twitter, there’s no UI to see all the responses to a tweet; you have to view them all individually. The comments also facilitate a conversation, whereas on Twitter, you’d end up with multiple tweets and no decent UI (save third parties perhaps) to view the whole conversation.
  • Mentions. Similar to Twitter @ mentions, but because of the comments, + mentions have more of a feel of being summoned into a conversation. It’s certainly easier to get the entire context of the conversation in which you’ve been mentioned.
  • Search. <rant> Seriously a shambles about Twitter is the inability to search through tweets. I can’t even search my own tweets!!! This was one of my initial motivations for using posterous, figuring I’d pipe everything through it. And same reasons others use identica, etc. The problem is you don’t get all the clients, e.g. Tweetdeck. So I ended up sending a lot of tweets which I can’t actually search through. They fall off Google and they fall off Twitter’s own search. It has constantly amazed me that a company in constant search for a revenue stream doesn’t have a full history of content available.</rant> Now, with Google Plus, there’s no search either, but at least advanced users have the option to search using And in all likelihood, we can assume Plus will have search too. (Although Android search shows Google + Search is not a foregone conclusion of excellence…but Plus’s virtues to date promise good things.)
  • Hangouts. I think the concept of video hangouts is immense, as opposed to just standard VC, and will be a great asset for remote teams. (I know some teams already just keep an open skype session running all day.) However, I’m speaking out of my speculatum because I haven’t yet tried it, for reasons explained below.
  • Updates. The team is doing a great job of engaging with the community, listening to the feedback, and making updates. They’re doing a great job if the worst controversy is closing down accounts of sophisticated tech companies blatantly flouting the rules by setting up corporate accounts, complete with filling in their first name, surname, and gender.
  • Android App. A fine production.

The Bad

Things not to like about Google Plus, keeping in mind it’s still in “field testing mode” (“beta” is so web 2.0) …

  • Circle statuses aren’t public. The problem is I want my Twitter-like geeky status updates to be public, but not contaminate the streams of my non-geek friends and family. There’s no good solution for this right now. If I publish a geeky status update to my “webdev” people, they will get to see it, but it won’t be public. If I publish it to “Public”, everyone in my circles sees it. Right now, I’m opting for “Public”, and if others are doing likewise, their non-geek friends and family will freak out the first time they join Plus and run fast in the opposite direction.
  • No groups. A lot has been said about whether circles themselves are a good idea, given that people’s relationships are nuanced and dynamic. But what interests me more than circles is groups. I’m really hoping Google somehow merges Google Groups with Plus; private groups would be particularly powerful for workgroups. The cool thing about groups, like what Facebook has but few people use is: (a) compared to circles, the visibility model is easily understood and predictable – someone can see messages if they’re in the group and can’t see them if they’re outside the group…simples! (b) you don’t have 100 people all adding the other 99 to the same circle and all micromanaging their circles to stay in sync – the owner just adds everyone once…this saves a lot of hassle, it works better for mainstream users who can’t or won’t micromanage circles, and ends up with a single source of truth.
  • Comments UI. As I mentioned on + Comments UI works for the average Joe with a handful of comments. But for Scoble etc, they are reedeeculous! 100+ comments in an hour? With no threading. It’s a mess to read and removes much of the incentive to post anything. This stuff is write-only. Since comments are +1able, G+ should let the popular ones float to the top, or perhaps display them with the others being collapsed. There are some other good suggestions in the comments to the aforementioned + post.
  • Comments and Sharing. The problem with sharing is people will comment on the sharer, not the original. I think it makes sense for everyone to be commenting in the same space, or at least for some easy summary view. I think this is Google being initially biasing towards privacy measures to avoid adverse reaction, but it does lead to comments being even harder to follow.
  • Finding hangouts. I can’t. Maybe that will change now that PlusRoulette is here! Or not. I also hope Google adds the ability to record hangouts at some stage. Lightweight video podcast ftw!
  • No metadata. I get it. Statuses don’t have titles or keywords or anything else because people are lazy and sites that don’t realise that won’t go mainstream. So Google’s being smart here. But that said, for my own use case, there are times when I’d love the ability to tag a post with “announcement” or whatever, so I can later have a feed of those. Anyway, I guess one can work around it by including some hashtag-like token in the actual status. Just making that point, though I realise my own use case is not that which Google is targeting – it seems the lesson has been learnt from Wave et al that Googlers and assorted geeks shouldn’t always be the target audience.

Okay, that’s me done. I’m enjoying Plus and I’m hoping it spurs Twitter and others to build on the awesome. Are you using it? Any other goods and bads?

Update: conversation on Plus

Will Bespin really end up with multiple backends?

Google groups thread

Bespin has the idea of multiple backends attaching to the same client. Right now, Python is apparently “winning” while Java has fallen behind and PHP appears to have faded away.

The situation is very analogous to Shindig ( which has a strong Java back-end, a PHP back-end that took a long time to get started in earnest and AFAICT from a quick glance has tapered off, and a number of non-starters.

I do wonder whether something like this is really viable – can you have a vibrant ecosystem of back-ends in different languages? Granted, there are hundreds of implementations of SMTP, FTP, and so on, in all the languages of the rainbow. Those are actual protocols based on strong standards. Likewise, Shindig had a fair crack at it because it’s based on the OpenSocial standard (but the diversity effort is probably hampered by the fact that most companies who want to be OpenSocial hosts tend to fall in the Java camp).

Bespin would need to formalise things and establish proper standards to support multiple backends. Nothing as onerous as the IETF standards, but still, they’d need to nail down all the subtle issues and edge cases in order to support multiple backends. Good for cleanliness perhaps, but at the expense of project velocity. Years ago, I asked SpringSource’s Rod Johnston about why one should use Spring over the upcoming EJB3, and one of his reasons – quite rightly – was that his code was available NOW while the committee-driven EJB standard and subsequent implementations were a long way off. In other words, Spring demonstrates that working, open, code is in many respects far more powerful than a standard. I can’t imagine Bespin will want to formally document its protocols; instead it will rely on code. But of course, if the code is a moving target, how easy will it be for different backends to keep up?

Also, how motivated will the second, third, and fourth guys be? It’s more fun being the first to see the concept become reality; less so to be building a port from one language to another. As with the previous point, though, I stand to be corrected; some people might enjoy the engineering challenge of building a parallel backend. (Maybe I’m being solipsistic here, as I’m personally 20x more motivated by user stories than implementation details.)

Java hosting is notoriously painful compared to the ease of cheap PHP hosting, so I can see the argument for both; companies will want to host Bespin on their own shiny enterprise Java servers, while rebellious little startups will want to do the same thing for a sliver of the cost on commodity iron.

Update: Ben Galbraith responds

The Canonical Design Sketch

We’re having a TiddlyWeb fest tomorrow, and I explained one of the things I want to get out of it is a canonical design sketch.

Luke Hohman’s superb text, Beyond Software Architecture, explains how he comes into a project and asks people to draw the architecture. A great predictor of the project’s state is whether people come up with the same diagram. Put crudely, if they are all on the same page – if they all know module X is in the top-right and module Y is centre left – the project is onto a winner.

I’ve found similar things myself. I will work on a project for a while before someone puts up a poster depicting the emerging architecture. People will then find themselves congregating around the poster and building it up.

While some people are more visual than others, I believe most of us have good spatial abilities and a team has a lot to gain from a shared understanding of the architecture. This is even more so in the case of a framework like TiddlyWeb, where the community is disparate and connected much more loosely than a group of agile developers in a room together.

A good example of a design sketch is that by a project with some similarities to TiddlyWeb: CouchDB.

I like the fact it’s a sketch, not a boring old “formal” diagram. Diagrams that are too neat are also brittle, whereas simple sketches are resilient to change. Moreover, I like the fact it’s on the homepage. That makes a bold statement to the community. This is the canonical design sketch for the project, and any discussions around architecture will naturally be couched around this sketch and the entities within.

Vim Macro for IDE-Like Behaviour

I find Vim easiest for browsing source and as I explore TiddlyWiki, I decided to use some fairly recent Vim features – vertical splitting and the explorer window. Combined, these give you the feeling you’re an 1988 edition of Eclipse. Just like a modern IDE, but navigation is ten times faster.

Here’s the macro – which assumes you just opened vim or have a single empty buffer:

map ]xx :Explore<cr>2jp<c-w>H20<c-w><

To switch files, navigate to the new file’s name in the explorer window, and hit “p” (the built-in command for “open this file in the previous location).

The macro:

  • Populates the current buffer with an explorer window
  • Jumps down two lines (to reach the second filename – the first name is often .svn)
  • Opens the file (“p”)
  • Places the explorer window on the left side (which also forces a re-orientation towards vertically split windows)
  • Resizes the explorer window to be 20 columns wide

While in the source window, you can still use commands like “:e filename” to open a new file (with tab completion) and ctrl-o/ctrl-i to jump back and forth.

The other helper is exuberant ctags, which I installed via Fink. I just run “ctags *.js” and then I can hyperlink from the file under my cursor using ctrl-], or visit any function using “:tag function-name”. (One remaining frustration is I can’t get it to hyperlink to OO methods established using the “ = function() {…}” idiom, despite including the pattern in ~/.ctags.)

Injecting HTML into an IFrame

Walking through Tiddlywiki source (write-up to follow), I noticed some interesting code in TiddlyWiki.js, importTiddlyWiki function.

The code takes a string and injects into an IFrame. I had talked to Jon a little while ago about a similar problem and was wondering about it ever since. The technique here looks like this:

It wraps the text with tags to make it an HTML document:


  1. var content = "<html><body>" + text + "</body></html>";

It then introduces a new iframe to the page.


  1. var iframe = document.createElement("iframe");
  2.     document.body.appendChild(iframe);

Now comes the tricky part. You would think you could just create a new iframe element and set its innerHTML, but with iframes you must use an internal doc ument property.


  1. var doc = iframe.document;
  2.     if(iframe.contentDocument)
  3.         doc = iframe.contentDocument; // For NS6
  4.     else if(iframe.contentWindow)
  5.         doc = iframe.contentWindow.document; // For IE5.5 and IE6
  6.     // Put the content in the iframe
  8.     doc.writeln(content);
  9.     doc.close();

Now the content is in our new iframe. We can then manipulate the content using standard Javascript…but ensuring a call like getElementById is executed against the iframe document, not the global document. (i.e. don’t use the usual document.getElementById()).


  1. // Load the content into a TiddlyWiki() object
  2.     var storeArea = doc.getElementById("storeArea");
  3. };

With this technique, you can take an arbitrary HTML string and delegate its parsing to the browser’s built-in DOM engine.

Tools Europe – Pre-Workshop Preparation

I have the honour of delivering a keynote at the Tools Europe conference in Zurich next week, as well as at the “Mining Web 2.0 Patterns” workshop, which, as you can tell from its title, I’m looking forward to participating in. The workshop chairs are Dragos Manolescu and Joe Yoder.

The keynote is on OpenSocial, Gadgets, and Design Patterns; and I’ll have more to say about it later. I believe it will be recorded too. For now, I’m using my blog to post my response for the pre-workshop preparation.

Sites and materials relevant to my presentation


  • Which features make the gadgets easy or hard to use, and how might the gadgets be improved?
  • At UI level, which best practice patterns are apparent?
  • What changes to the platform would improve user experience?

Sites and materials relevant to other workshop tracks

Site Navigation:


Coding Standards Suck

Coding Standards, Software

… because they are dogmatic. Coding guidelines are just fine, but coding standards imply:

  • There will be an automated tool that checks your conformity to guidelines, leading to (a) inability to check in your code; (b) public shame; (c) much head-banging on keyboards
  • A smug sense of unjustified satisfaction from the kinds of people who add little value to the development process
  • Developers are thick-heads

As a devotee of literate and self-documenting software, I frequently find cases which break my own default preference. A simple example is a data structure where geometrically splendid code layout will aid comprehension, e.g.:

  var fibs    = [ 0, 1, 1, 2,  3,  5,  8, 13, 21];
  var squares = [ 0, 1, 4, 9, 25, 36, 49, 64, 81];
This is of course laid out so you can easily compare the value at each position in the array. But under some dogmatic coding standards, you are incited to make the code considerably less comprehensible:
  var fibs = [0,1,1,2,3,5,8,13,21];
  var squares=[0,1,4,9,25,36,49,64,81]
That’s a simple data structure example, but the same thing can happen with control flows as well, where you might want to sometimes use whitespace, sometimes use a curly brace at a different place, etc.

Another example – which I’ve mentioned for years on this blog – is the craziness of setter and getter dogmatism. Instead of:

  public void setName(name) { = name; }
  public void getName() { return name; }
  public ...

… you end up with:

  /* Sets the name. Duh. */
  public void setName(name) { = name;

/* Ehm. Well I suppose it gets the ^$()* name .Bozo!*/ public void getName() { return name; }

public ...

… How’s that for a five-fold increase in your LOC, if that’s what you’re getting paid for!

Competent programmers can make these decisions and decide when it’s reasonable to deviate from coding guidelines, and if you’re relying on an automated system to check code, maybe it’s time to start running code reviews or pair programming. The problem is, they’re not allowed to by heavy-handed Coding Standards.

In Extreme Programming, coding standards are defended on the basis of collective ownership; the argument is that each team member has their own taste, so code would forever be thrashed back and forth as each programmer rotates on to it. Once again, though, this is fine as long as coding guidelines are in place. The example above is something all programmers can agree on, but would still fail some automated systems, or fail to be generated correctly by a tool like Eclipse. There will still be arguments, but probably not many if the team is thinking alike, and those will be arguments worth having.

There’s also a view that coding standards support faster development, by letting you focus more on cranking code out and not on hand-crafting each line of code. Well, I’d rather hand-craft each line of code and make it as valuable as possible, refactoring and refactoring it; IMO a good team and environment can produce code that’s one-tenth the size of equivalent code created by a mediocre team. That’s ten times less code to maintain and ten times less code to confuse. To wit, 37Signals took TadaList – a reasonably successful app – to production with just 579 lines of code. With tight code like that, you ought to treat it more like prose and less like a can of dog food on an assembly line.

As t → zero

Andy Hunt asked a while ago, What happens when t approaches 0?”

One of the interesting topics that came up today at Software Trends was “what happens when the time to develop a new application approaches zero?” It will never be zero, of course, but it will, over time, asymptotically approach zero. Suppose we finally get to the stage where a single developer, sitting at a laptop, can develop an application as fast as the end user/sponsor/customer can describe what they want.

I’ve been noticing a few web projects lately that are built at light speed. There’s nothing new about this as I’m sure lots of cool programs in history were written in a day or a weekend. Still, websites are the coolest programs in history because they’re immediately accessible by the whole planet, so it’s great to read about these projects happening. Thanks to the power of social networks, blogging, etc etc, it means a new service can come on and immediately its creator gets an idea about how big it will be and where to take it.

Here are some examples:

  • Startup Weekend brought 70-odd people together to build a new startup in two days. The blog from the event and the blog of the subsequent website, VoSnap is candid and the insights and admissions fascinating.
  • TwitterVision was built in four hours.”>built in four hours. This is, at present, my canonical example of lightning-fast development and the power of the mash. Not just spiking the concept, but actually a full delivery. (Twitter itself is rumoured to have been built in a week, which seems fair as it’s more the idea that makes it what it is.)
  •, which claims over a million big file downloads, was built by two guys in a weekend in ’05, two normal 8am-6pm days. Here’s how
  • RailsDay challenges developers to build something real in 24 hours. (The idea is sound, though execution lacked apparently, hence no repeat this year I guess.)
  • Yahoo! HackDay encouraged fast mashups and led to the GetUsOrganized startup.
  • AnAppADay The “software jedi” wrote 30 apps in 30 days. I’ve often contemplated taking a week off and doing 7 websites in 7 days. I’ve got enough ideas and can code them fast enough to get something out with Rails, the problem is deploying in a manner that’s stable, cheap, and secure. Looking forward to the day when Rails deployment becomes as simple and cheap as PHP … or maybe I should just bake cake.

The only thing wrong with GoF Design Patterns is …

Jeff Attwood recently pointed out the difference between Gamma et al’s Design Patterns and Alexanders’ equivalent and outlined a critique of the former which characterises it as “replacing actual thought and insight with a plodding, mindless, cut-and-paste code generation template mentality”.

First, I want to note that the critique above surely defies belief to anyone who has used the patterns in practice. Patterns like the GoF design patterns are grammar for software architecture. If you search the technorati archives from when grammar emerged many millennia ago, you will probably find one or two bloggers was bemoaning the loss of creativity that this concept of sentence structure will cause. Fortunately, sense prevailed and now writers can be creative about the things that matter and not have to micromanage those that don’t. The progression of any discipline involves a cycle experimentation followed by optimisation followed by explicit statements of best practice (patterns), spiralling upward in level of abstraction. If I was so inclined, I’d go make a T-Shirt on CafePress that says “Patterns Take You Higher” with a picture of Bob Marley refactoring to Template Method.

So the GoF patterns are perfectly choice by me. The main problem with them is not the content per se, but the fact that most software developers think that pattern==GoF pattern and pattern language==the 23 patterns by Gamma et al. (1995).. If there’s ever a sequel, it would double the number of patterns in the universe according to these folks! In fact, there are thousands and thousands of documented design patterns out there, in the realm of software alone. (Admittedly, the most popular realm for design patterns, though there are still plenty of patterns for other disciplines too.)

This perception is silly.

Why do software patterns != GoF patterns? We can expand out from the GoF patterns in several dimensions (even staying within the realm of software):

  • Architectural Paradigm Even with patterns of high-level software structure, like GoF, we can model different architectural paradigms. GoF is all about general-purpose OO architecture; if you wanted to work with functional or logical languages such as Haskall or Prolog, you would need different kinds of patterns.
  • Application Type GoF patterns apply to the general structure of any medium+ scale architecture. There is still a wealth of advice to be gained from studying existing applications of the same type as you’re working on. This could be web server design, in-browser script design (like some of the Ajax patterns), mobile phone design, etc. For instance, the various J2EE patterns around, which were probably the second best known category of patterns in the industry (trailing GoF by a long margin though).
  • Perspective People see software from different perspectives; GoF patterns see it from that of a technical architect working close to the ground. You can also see patterns from the perspective of a user experience designer (usability patterns), project manager (software development process patterns), business analyst (business process patterns), programmer (coding idioms), etc. In this paper, we explained how patterns for usability alone could have all sorts of representations.
  • Domain The GoF patterns apply whether you’re working in banking, gaming, or web design. But each of those fields have their own idiosyncracies and fortunately there are pattern languages which capture them.
  • Opinion Even if you aim for the same problem space as Gamma and colleagues looked at, you will have your own views on the correct solutions. Patterns are opinionated, not objective, so your patterns will differ from theirs. As time goes on, any static set of patterns will naturally become less valid – it’s a testimony to Gamma et al that the patterns remain so very useful 12 years on (that’s a 256-fold increase in processing power according to Moore’s Law, and industry transition from C++ through Java and .Net through to Javascript, Ruby, and Python). Still, they’re not perfect; Singleton anyone?

One of the reasons the Gamma patterns are so successful is the fact that they apply so universally. However, this also leaves room for other patterns to come in and provide more specialised support.

Ajax Patterns has certainly been subject to this misconception; one review liked the content but prefers not to see it as a real pattern book – “Anybody who has read a real design pattern book and then read this book will soon feel the artificiality. ” Another refers to Gamma et al as “I read the original ‘Design Patterns’ book” and states “Those that read the original book will understand that packaging these topics as design patterns is insulting to those that know the value of actual design patterns. “. After many years of explaining usability patterns, I had anticipated these concerns with an appendix explaining the difference, but moreover explaining that it’s the content that matters most. There is also a perception that “Patterns” in the title sells more copies; all I can say is “I wish” as that buzzword went out the window around 2002. It’s called “Ajax Design Patterns” because they are, well, Ajax Design Patterns.

Bill Sanders gets it and recently discussed this phenomenon:

Buried in Appendix C (pg 605), Mahemoff distinguishes his use of design patterns from that of GoF, but it is not the kind of place that most developers are going to look when they pick up a book about Design Patterns. Likewise, Mahemoff uses the inside front and back covers to list the Ajax design patterns. On the one hand, anyone who reads those pattern names is going to know that this book is not about the kinds of design patterns GoF examine. On the other hand, the fact that the patterns are listed there, just like the GoF book, is a sincere form of flattery in the form of imitation.

Bill makes a good point about the Appendix C content being buried. Actually, relating the second point back to the first, I had in mind the similar statement by Gamma et al about Alexander’s patterns and their relevance, which also appears at the end. Still, in a pattern book, I’m not sure where to put something meta that won’t be buried; I’m sure the preface and intro are read about as much as the appendices. And I’ve certainly discussed the issue online before.

As for the covers, I liked the idea from GoF as well as Fowler’s UML Distilled book, and was particularly insistent on this because O’Reilly couldn’t do page cross-referencing.

Mahemoff is quite right in noting that the “original” design pattern book is Christopher Alexander et al’s town planning and architecture patterns book from the 1970s.(In fact in the Foreword to GoF’s DP book, Grady Booch mentions Christopher Alexander’s work.) However, common usage of design patterns in the context of computer programming has come to mean the kinds of patterns GoF talks about. Head First Design Patterns is a good example. No one was disappointed because they were surprised by the meaning of design patterns. Common usages in a given context come to have a specific meaning. In the world of quilt-making, design patterns mean something entirely different than in programming, and so no one is surprised when they get a book called Quilt Design Patterns and find out that there’s nothing about the Creational, Structural, Behavioral Design Patterns. However, in the world of programming, that is exactly what can (and did) happen in the case of Ajax Design Patterns, despite the fact that no less than Ralph Johnson reviewed parts of it.

(Emphasis mine) Yep, if you published a book of music patterns, there’d be no confusion. Still, I think our industry misses out because of this confusion. In an ideal world, there would have been 2 or 3 equally big hits at the same time, to get people’s mind around the fact that patterns are everywhere, not confined to the one (albeit excellent) text (I was going to call it “bible” but the one time I met John Vlissides, he told me he didn’t like it when his colleagues called it that :)). As it is, there’s the big ‘un, a few prominent others – typically in similar “high-level architecture” style to that one (e.g. the J2EE books, the POSA series and some of Fowler’s work), a bunch of books which used “pattern” for the hype value, and thousands of other books and one-time papers and blog entries. At one stage, Ward Cunningham was going to work with Microsoft to build PatternShare, a kind of meta-repo for all things pattern, which may have changed things, but apparently it never happened and the site is now down.

Quite apart from the book’s title, Mahemoff, does take up the invitation to contribute to design patterns offered up by GoF and he documents a number found in Ajax. While on a different level and with a different specific meaning than that found in GoF book, Mahemoff provides a wider view of design patterns and has what may be the best Ajax book on the market. It would be a shame if his work is diminished by the title, but among some, especially on the higher end, that may happen. Fortunately, the bulk of the reviews are readers who were looking for a good Ajax book and got exactly what they wanted.

This is where things get even more confusing, because the Ajax patterns (as with just about any other form of software pattern) actually relate to he GoF patterns. They’re different, but not entirely orthogonal. For instance, the daddy of all UI patterns, Observer, is present in patterns such as Virtual Workspace. My attitude is that patterns are there to be referenced and so I will happily reference other patterns from other languages if need be. In my mind, it’s all one big network of patterns (a PatternShare wiki, if you will).

Podcast: Metaphors and Analogy in Software

It started with this Code Craft blog post on the Code Garden – an analogy that sucked less. It got me thinking and ranting about metaphors in software and metaphors of software. Designing your technical architecture with software, the XP “Metaphor” practice, metaphors for HCI, metaphors like those used in the Head First series and Ajax Patterns to explain concepts, metaphors to explain what software is to managers. Where do they make sense and where is it plain wrong to try and explain software with a metaphor.

22 minutes.