Skip to content

97 things …

I just came back from a great week in Tasmania. It was really good to be away from communications infrastructure for that amount of time – there’s no mobile service in many parts of Tassie. You can see the photos on my Flickr photostream (although it might take me a couple more days to get them all up there!).

97 Things Every Software Architect Should Know

97 Things Every Software Architect Should Know

While I was away I’ve become a published author. I contributed to Richard Monson-Haefel’s project 97 Things Every Software Architect Should Know, out now via O’Reilly, there’s a great related project site here. You can buy the book from Amazon. It’s a bit of an ego boost to get one’s name included with such illustrious company as the other authors like Gregor Hohpe (and also to be described as an “expert” whose “wisdom” has been collected!). Personally I found it really hard to come up with an original axiom expressed eloquently enough to be satisfied with it – I only came up with a single axiom for the book and that was hard enough. Rather than hard-and-fast rules, I think you should think of the book as a collection of 97 personal koans that you can apply to your personal practice of software architecture.

There is a preview from O’Reilly here. There is also more background at Richard’s blog, at Burt Hufnagel’s blog and also discussion on The Server Side.

The content of the 97 things project is actually creative commons, and there’s more of these books in the works. It’s an interesting concept in open source collaborative publishing so lets hope it yields results.


  1. Ben wrote:

    This one alone makes me want to read the book:

    Too many developers get bitten and bite others in the arse trying to be clever by showcasing their intelligence instead if implementing the _right_ solution…

    The odd thing is that in the field of mathematics you get points for _avoiding_ complexity — most clear / elegant solution wins.

    Why is it that developers have such a big insecurity about their intellect that they need to show off how many frameworks or language quirks they know?

    Saturday, February 28, 2009 at 00:31 | Permalink
  2. Robert wrote:

    Ben – at least one reason is that it’s _easier_ to be “clever”. Introducing complexity into a solution is trivial, and nearly always solves the immediate local problem being looked at. Keeping track of all the consequences added into the global problem is difficult.

    As developers, we tend to design solutions in such a way that adding or extending the solution is a solvable problem. However, you can’t add simplicity – simplicity is achieved by removing things. Working out what can be safely removed, and what can’t, is hard. Particularly if you don’t have an intimate understanding with the problem domain _and_ with the technology.

    Finally – in mathematics, you have a bunch of people who get paid to look for ways to take existing solutions and make them simpler. In software, there is no such luxury.

    Saturday, February 28, 2009 at 08:11 | Permalink