Ceterum censeo, Carthago delenda est

So, anyway, the reason we left Sydney was to come to Nagoya. As I recall the proposal went like this:

Nagoya is the hot choice right now! It’s on fire! Set your burners to exciting! An inferno of activities are waiting for you. Plus, come now, and we’ll throw in a free sauna!

Well, maybe it wasn’t quite like that…. But the sauna bit is true. At least until autumn.

Anyway, for the next 18 months, I’m in Nagoya, working on the Japanese side of the same project I’ve been working with for the past two years. As a career move, it can’t go wrong - the experience is naturally hedged.

Wifey and I are not installed in a quite lovely home, enjoying the fruits of having finished the move, which was rather grueling. Lovely wifey has pictures and things, if you’re interested.

For me, the main goal is getting over the crippling combination of warm days, rice for lunch, and mental overload. Struggling to stay awake is simply embarrassing.

A month ago i left Sydney for other pastures, after 18 months living there. I have these observations to make:

1. It rained a lot in Sydney. That good weather image they’ve been cultivating for the past 10 decades - lies.
2. Sydney is an expensive place to live. The price of groceries is much greater than in Melbourne.
3. Sydney isn’t that interesting a place to be.
4. AFL is vastly more interesting a game to watch than either rugby code.
5. Sydney doesn’t do decent fish and chips.

Now, after 18 months, how reliable are my observations?

1. A long lasting drought broke. Plus we were in the wettest part of Sydney metro area.
2. The price of groceries rose everywhere the past couple of years.
3. We lived in the Shire. All of Sydney would agree its not interesting, except possibly the surfers.
4. …this one is true
5. …so is this one.

Possibly a moral about the limitations of anecdotal evidence. Or possibly an example of how overrated Sydney is. I’ll find out when I have to move back, in a couple of years.

I recently attended a speech by a motivation speaker, who exhorted passion in the workplace. Her idea of passion seemed to be enthusiasm, or rather, anti-dreariness. As far as I’m concerned, she didn’t get it.

I’ve worked at a couple of workplaces where people were passionate about their work. Here’s what I noticed:

• Passion leads people to want to learn new things. It creates a desire for self-improvement.
• Passion leads people to argue about how to do things. Endlessly.
• Passion leads people to want to share what they find. (This blog is a pretty direct result.)
• Passion leads people to get annoyed when something is done wrong. (All right, maybe this is just me. Some of my blog posts have this route.)
• Passion makes it hard to settle.

Frankly, passion is going to disrupt any workplace that isn’t already close to excellent. If the workers aren’t able or allowed to reshape the workplace, it’s going to make them miserable.

There’s a certain brand of testers who, in order to sharpen their testing skills, will ask how to test a common object… say, an http://quinert.com/blog/index.php/2006/02/13/index.php?itemid=46&catid=4, or a stapler. It’s a good way to show and improve testing technique, because of the way it brings out testing teachable moments.

It’s generally a struggle to do the same thing for BA skills. There’s little parts in which in works. For example, show the weakness of documentation by asking someone to document how to tie a shoelace. (Anyone who writes instructions can be safely hired to do your filing.) But when it comes to any sort of real analysis, it’s hard to find a subject of meaningful complexity where everyone shares real domain knowledge.

However, I believe I have a candidate: time sheets. We’ve been asked to fill in some rather ineptly designed spreadsheets to track time.

Ask a prospective BA to write requirements for a time-sheet system.
Give a 5 minute interview you to find the scope.
Ask them to come up with a potential solution.

I wonder if this could be done in an hour…

Here’s a tale of two contracts.

1. A project team develops a Java based application, and gets all worked up about installing software on third party machines of unknown configurations. They go to the legal department for a contract covering the liability issues involved in installing software. The result is a T&C statement interchangeable with every software EULA you’ve ever failed to read. Wider ranging business issues (e.g. ownership of information, liability) are completely overlooked.
2. A business department has an ill-defined legal relationship with various third parties, and gets worked up to resolve this. They go to the legal department for a contract covering the liability issues involved with accepting goods. The result is a T&C statement about, oh, lots of things, all definitely business related. Other technical issues (e.g. availability, authorization, software requirements) are completely overlooked.

In both cases, the legal department provided exactly what was asked - a disclaimer that answered the risks that worried their immediate client. In neither case does the legal department raise other risks. The legal department is a service center, just like technical departments. They answer the questions put to them, and have limited capacity to seek out new questions. (In fact, the client would probably be resentful if the lawyer started forcing changes to products in use, since a) it’d be outside the product development life-cycle, and b) no one likes a visit from the auditors.)

The same thing applies to the technology service centers I’ve worked in. It’s extremely hard to get out of the engaged scope and into business process. Some of this is internal… projects generate a certain tunnel vision. But a good deal of it stems from the terms of engagement - when you’re engaged for a specific problem, a wide ranging investigation into underlying business issues is simply irrelevant.

Modeling a department along customer service lines hamstrings the ability of the department to actively engage… the model and mindset just doesn’t allow it. Of course, the Customer model is a reaction to the previous Priesthood model, where IT departments had complete control and no accountability, doling out new software as and when it choose.

Partnership is another model, but needs the department to be deeply invested in the particular business, so that they have the knowledge to identify opportunities when they arise. It sounds nice, but is going to struggle with the fact that you can’t be partners with everyone.

Another model is Federation. Each business has it’s own IT development team, which focuses on that single business. Meanwhile, there’s a central management team focused on long term standards, which manages support, standards, architecture, HR, skills building, and all the various bits that prevent the company IT fragmenting into separate operations.