Culture (The real stuff)

A long while back I almost ended up working for a truly innovative consultancy in Australia, but then I thought better of it. Seriously - you can't be a thought leader in Australia.

At the time I turned down the offer I had a vague sense that there was something about Oz that would make it a challenging place to be employed by a very American style consultancy, but I couldn't actually put my finger on it.

Now I know that we don't like leaders (especially self-appointed ones like consultants), and we're at best ambiguous towards thought. So saying you offer "though-leadership" is just going to get your head bitten off.

That's probably one of the things that makes this country the best, freest, places on earth; but it can make working here a bit challenging sometimes. It's probably why our most successful leaders (Hawke, Howard) are people you can imagine having over for a BBQ.

Just as an example watch me miss-communicate badly with an American over at Bridging-The-Gap. Even though I agree whole-heatedly with the sentiment, I just can't help pointing out everything that could go wrong. Of course as an American she can't help but respond with how excellent everything is; and because I'm an OCDD bastard I can't help but provide a few links in return.

Why? Because I'm an Australian; and that's what we do. We don't complain as such, we just like to point out that things won't work, and that if they do by some miracle there will be some other problem soon.

Of course there's also that stubborn streak and black humour, that keeps Australians going even as they're saying the whole thing will fail. If I found a company with that I'd sign up in a flash. I reckon Atlassian may have been one such company before it got big (Ironically it was Confluence I was discussing with the afore-mentioned American)

I should thank Professor Spillane for this insight. His philosophy course as part of my MBA was actually education not just plain old training. Probably made me a frummer yid too.

Update: I forgot to add the most important part: how you should actually sell yourself in Australia. The following has worked OK for me:

• Emphasise experience, not knowledge or acclaim. Saying you've been doing this for ten years is good, saying you wrote a book on it is bad.
  
• Sell avoiding negatives not massive improvements. Aussies (rightly) don't trust over-the-top sales pitches about how good everything will be, but we are ready to listen to someone who says that they have tips on how to avoid the worst.
  
• Be clear about trade-offs. We will instinctively look to denigrate any innovation, but by being clear on the down sides as well as upsides of what you propose at least you're part of the conversation.
  

P.S. The money at this consultancy was also bad - which was obviously the real-reason I didn't take it.

P.P.S. Who are the people are actually reading this blog. When I started it it was just to keep in touch with a team of BAs that were on multiple client sites, so I'm pretty shocked that anyone who doesn't know me would take this time to read it.

Brilliance of Use Cases

Use Cases in whatever form are probably the single most wide-spread and effective requirements gathering tool for one really simple reason:

 

They close the gap between narrative requirements on one side, and a specified design on the other.

 

It really doesn’t matter what you’re calling requirements and what you’re calling design (No matter what you call design I’ll find someone who’ll call it requirements). You can always use some form of use cases to close the gap between the narratives that the consumer of the deliverable experiences and a specification of how the deliverable will provide that experience and respond to inputs. Whether it’s a user story, business use case, API use case, or anything else; use cases close this gap like nothing else.

 

In my experience they’re the one deliverable that’s as useful for users and developers if done right. There may be other deliverables more suitable for specific project, or better for some stakeholder group, but you can’t go too far wrong starting off with use cases.

 

In a way they’re the quintessential BA artefact. They’re a Rosetta stone that talks to both the users, and the deliverers in their own language.

 

P.S. Yes  - I know it’s pretty useless to talk about Use Cases.  Let’s just assume I mean the term as a generic catch-all term for everything a reasonable person could call a use cases. I should be a post one day about my two dimensional model for describing the different sorts of Use Case.

 

P.P.S. I have strong opinions about BABOK vs IESB. How geeky am I?

Broken Metaphors

The number one cause for bad software design is using the wrong set of metaphors for a solution.

 

Excel and the Macintosh Equivalent (Numbers) is a perfect example. Excel's core-metaphor is functional; but once you spend more than five seconds looking at a Numbers screen you realise that it's wrong. It's wrong for all sorts of perfectly justifiable reasons, mainly historical and compatibility, but it's still wrong.

 

·         Excel: Sheets are full of cells of calculations or data. You can have multiple sheets.

·         Numbers: Pages are full of tables of information. Each table can contain cells of data, calculation, or a mix. Wikipedia calls this a “Layout of lists” metaphor.

 

Essentially numbers separates out how block of information are presented (Pages) from grouping related numbers (Tables) where excel groups them together into the one metaphor (Sheets)

 

So what? Doesn’t introducing more core-metaphors just make the solution harder to learn? Well no, once you have metaphors that match up with how users actually do things other functionality falls into place a lot more naturally.

 

Take for instance formatting of tables. In excel if you have multiple related squares of information you’ve got to adjust the formatting cell by cell, range by range; in Numbers this is more natural as you have a “Table” that can be directly formatted.

 

Or take referencing between tables. In excel lots of users will never use more than one sheet because they don’t feel comfortable using cross-sheet referencing, but in Numbers it’s seamless as you can directly reference a Table and calculation (Total of Sales, instead of “Sales!A23”)

 

It also just makes Excel ugly when used without much thought, where Numbers produces quite clean well laid out pages if just used in the “natural” way.

The Excel product team get this. Recent versions of Excel have a concept of Tables, but they’ve had to hack it on top of the Sheet concept to keep backward compatibility.

 

In summary – if you get the core metaphors right up front then everything else is simpler. Don’t be afraid of making the core metaphor a little more involved; it could save you a lot of complexity in the long run.