Things Every Software Architect Should Know

I stopped reading after One line of working code is worth 500 of specification and It's never too early to think about performance.

I thought this philosophy was proven flawed!

I think the problem with this book is not about recipes it gives, and way how it approaches the problem, but the problem itself. I spent 8 years working in different software companies, and never met a person with the 'architect' job title, whose job would be different from one of either developer or manager.

Therefore, I personally do not believe in 'software architects'. And this book supports me in this! I went carefully through the list, diving inside some specific topics and it seems that all of them (or overwhelming majority) lie in the field of responsibility of someone who could be described by job title other than architect. "#12 There is no one-size-fits-all solution" -- fine, development issue. "#17 Business Drives" -- fine, management issue. And the the brightest gem of all: "#80 Dont Be a Problem Solver".

Nothing's proven flawed. Both of those pieces of advice work under the correct, narrow circumstances.

If you're building a web start-up, forget specifications. Write code. There is no way to have the slightest clue what you need to specify anyway. Write something that does something useful and put it in front of some users. Go from there. In different circumstances, of course (e.g. while building the software for a major Stock Exchange), this is the absolute worst thing you can do.

If you're building your start-up, it's almost always too early to think about performance. You need to have some vague awareness of whether it will be possible to optimise your code later and keep it clean and simple so that it remains possible, but ultimately I've found that it pays to optimise at the last minute - i.e. optimise when there are performance problems, not before. On the other hand, going back to the major stock exchange example, performance there is likely to be one of your major challenges, so you need someone on the team who is performance-minded and has built a stock exchange before, so that they know where the bottlenecks will be and can ensure those are avoided.

I skimmed through a few. There are a lot of platitudes in there, but a few of them are useful reminders or elaborations of things we know "in the bone", like #18 and #24.

It's never really too early to think about performance. All you have to do is try not to act early on that. A lot of architecture ideas we have (sane URLs, caching servers etc) are rooted in performance considerations.