Posted on 10 Mar 2009
On the weekend my copy of 97 Things Every Software Architect Should Know arrived. "So what" you say. Well, a short article I wrote was selected for inclusion in the book. This is exciting given the quality of the other contributions. My previous book writing experience was limited to the "Statute Expert Programmers Guide" and a few chapters of another Statute Expert manual/guide - given the niche nature of SoftLaw's technology neither book was a big seller or even readily available. Having something available on Amazon with good reviews is nice. As the title subtly hints, the book contains ninety seven short essays/articles/axioms/comments/principles relating to the practice of software architecture. The short bite format allows the content to be digested in small chunks and makes browsing a rewarding experience. I've learned from the book and if you have anything to do with creating software then I expect you will too.
Posted on 23 Jan 2009

The problem

I love the 24inch monitor I have at work and my co-workers know it. I'm on leave right now and they sent me this picture of my baby being abused. Michael J licking my monitor

The solution

I created a little site called if you touch my monitor you will die and sent the culprits a link to it. If you suffer from the same problem feel free to make use of ifyoutouchmymonitoryouwilldie.info to create a little bit of a disincentive.

The result

It didn't really work - the next day I got this sent to me: Lots of hands touching my monitor Oh well.
Posted on 08 Feb 2007
This is one of those chicken and egg problems.  You are a nerd working on a team and you think that you'd all do well if there was someone responsible for the architecture (or design or builds or tests or...).  In fact, you think that you are the perfect candidate.  There isn't a job opening.  Nobody has announced the need.  What do you do? Should you talk to you boss and suggest that you starting doing it?  What if she says that she can see that such a role might be needed but that you don't have any experience?  What if she says that your teammate Max would be better at the job and calls him into her office? As you might guess I think that the best thing to do is to starting doing the job on the side.  It will probably mean extra work.  It will probably mean needing to convince co-workers that your ideas are worth it.  However, the best way to show that you can do something and that its needed is to do it.  Be careful not to be sneaky and be sure that you aren't stepping on anyone's toes too hard.  Unless you work in a toxic environment your efforts will be appreciated and rewarded even if you aren't successful in changing you role.
Posted on 08 Feb 2007
Dwight Shih has tagged me with the surely dead (except for me) five things meme. So in order to not be too curmudgeonly here I go:
  1. I've got two kids, a 5yo and a 13mo and a lovely & intelligent wife.
  2. I live in Canberra, Australia.
  3. I love cooking even more than I love nerdery and software development. That's a lot.
  4. I've worked part-time for about five years now and I recommend it to anyone who can afford the cut in income. Especially if you are a parent - there is nothing like having a spare/bonus/free day every week to spend with your kids. That is until they start full-time school like one of my kids just has.
  5. My first job after I finished university was working for a startup working on an expert system shell in Prolog (and C). Much fun and hilarity ensued.
I take it I'm supposed to pass the meme onto some others so here goes - Justine and Iang your numbers are up.
Posted on 05 Dec 2006
I've just started leading an internal workshop on Incremental Development. In the workshop I describe and delve into the difference between orienting development vertically (by use case) versus horizontally (by software layer or service). By use case is the clear winner since it allows progress to be tracked in a user meaningful manner and encourages a smooth flow of client value. Johanna Rothman describes the different orientations as implementation by feature and implementation by architecture. These are clearer phrases. I think I'll be making a few minor edits tomorrow.