I’ve been having some interesting exchanges with Software Architect friends of mine in the last couple of weeks. I’ve been asking for pointers to the most interesting and influential books on Software Architecture, and keep getting the same response, which is something like: I used to read tons of books on architecture, but now I focus on business strategy and communication skills. Architects don’t fail because of an inability to master the technology, they fail because they can’t convey their ideas or listen to others at the right points in time. This is encouraging to me. These days, there are clearly key architectural points in system development, but the way to solve them is to have your eyes wide open, be analytic, and listen to the smartest ideas in the room (or from anywhere). My initial take on the Zen of Software Architecture was
The central skill is knowing when to kludge, when to refactor, and when to call bullshit.
A friend of a friend has a simpler version
There are 2 rules: 1. Don’t think, hack 2. Don’t hack, think. The trick is using the correct one
Now that I feel firmer in my conviction that architecture is really about finding clarity, I’m delving into the books and articles that have been recommended. I’ll be sharing some of that reading, and the reading list, in later posts.