Book Review: 'Scalability Rules: 50 Principles for Scaling Web Sites'

I absolutely love Technical Architecture. It is something that requires high standards in engineering to do well.  In 'Scalability Rules', Martion Abbott and Michael Fisher detail 50 tips, where each tip communicates a simple or sophisticated idea in a few short pages. Their ideas are based from real world experience of working with over 200 internet architectures.

Performance and its cousin Scalability are always an important part of any software architecture and while some cynics will say some of the tips in this book are common sense, there's plenty of really good advice that if adhered to would certaintly lower the probability of scalability issues which are nearly inevitable at some stage in the life of a project.

Among my favourites tips:

• Put Object caches on their own tier. This makes it easier to size their hardware needs - object caches typically need a lot of memory. It it easier to organise and control this when they have their own tier.
• Pass on multi-phase commits if possible as they are difficult to scale.
• Smart reminders such as when it is really important to use aschronous models (integrating with 3PP frameworks, when there is a temporal constraint etc).

I wouldn't just recommend individuals to read this book, I would recommend teams read it. Some important ideas such as spliting up system processing by something like customerId are given concrete names such as Z-Axis splits. The would help teams speak start speaking the same language when communicating ideas. It would also help to remind teams that some simple things such as using logfiles, monitoring your system properly and not relying on QA to find faults that should be found earlier are very important and should not be forgotten.

In summary, there are not too many good books on software architecture and this is certainly one of the best I have read. I have already read parts of it 3 times and I am sure I will be referring to parts of it again.

Book Review: 97 things every Software Architect should know

You can't judge a book by its cover but you can certainly ask questions about its title. Why '97 things every Software Architect should know'? Why not 98, 99 or even 100? Well the word on infoq is that they wanted a number near 100 so that there would be enough material for a reasonably sized book. Fair enough so... The book contains 97 articles published by a range of software professional expressing their views on various aspects of software architecture. Many of the articles are not very technical in nature and there are - perhaps - a lot of similarities between this book and '12 Essential Skills for Software Architects' where author Dave Hendricksen focusses on non-technical skills essential to be a succseful architect. Other articles probably aren't just things an Architect should know but really things anyone working in Software Engineering could benefit from knowing and thinking about. I even include Project Managers in that!

That said, there are some really enjoyable bits and pieces. My favourite parts:

• Keith Braithwaite's reminding of the architect's need to quantify things. Characteristics such as average response time should be not be phrased using terms such as 'good' or 'satifactory' but quantified as something like: 'between 750ms and 1,250ms'
• Craig Russell's points about including the human interaction time in any performance analysis. The system may respond very fast to API calls, but the if the UI is counter-intuitive, it means the user will spend a longer time try to get his result.
• Michael Nygard advice for engineering the 'white spaces'. Don't just have arrows between components specifying the communication protocol, describe the performance expectation of interaction e.g. 100 requests per second, response time 250ms 99% of time. Describe how the system will handle overload, bad response times, unavailability etc.
• Mark Richards classification of architectural patterns:
• Enterprise Architecture Patterns: EDA, SOA, ROA, Pipeline architecture
• Application Architecture: Session Facade, Transfer Object
• Integration Patterns: File sharing, RPC, Messaging
• Design Patterns: GoF

• Gregor Hohpe arguments about the 'predictive call-stack architecture' becoming a thing of the past.
  In massive distributed systems, it's not so easy to define the order things happen in. Architectures now have to be able to respond to events in any time order.
• Bill de hOra discussion of inevitable tradeoffs using Brewer's conjecture (CAP) as an example.
• Dave Anderson's arguments for the inevitabitly of legacy and preparing your system for maintenance.

So plenty of good advise in a short book that never gets too technical. The role of the architect is not just to be capable of understanding complicated problems but to stand back and look at the big picture, checking for gaps and to ensure the right actions are taken to ensure project success. This means it's not really just about things a software architect should know, but about things a software architect should ensure they never forget. 

Book review: 'Are you smart enough to work at Google?'

You need to toss a coin for a football match. The only coin you have is bent and biased towards one outcome. How do you use the coin and ensure a fair toss?

I love a good a puzzle and there are certainty plenty of thought provoking mind benders in this book - most of which I had not heard before. Author William Poundstone (author of 'How Would You Move Mount Fuji' and 'Fortune's Formula') describes various puzzles that are describes various puzzles that are likely to be part of a Google interview process - that company now estimated to be running over one billion search requests per day!  Some other aspects of Google are covered, but the subject matter is predominately puzzles - all types of puzzles: fermi questions, deductive logic, numeracy skill, algorithmic questions and some grade A counter intuitive mind boggling teasers!

William Poundstone

One can't help asking the question why Google bothers with all of this?  Surely, the point of an interview is to see if someone can do a certain type of work and the interview should be a fair attempt to assess a candidate's suitability. I have had the fortune (some would say misfortune) to be part of world of Software engineering for the last 15 years.  I am passionate about it, but I'll be the first to admit it isn't just about solving fun puzzles. Following best practises, following agreed processes, keeping up to speed with technology, documenting solutions so others can see what's going on are all very important things to make a good software engineer.  And it's not always sexy work.  Sometimes it requires patience  debugging ugly code while sticking to a tight project deadline. Ascertaining how good someone is at all this in an interview setting can be difficult - especially when it's very easy for a good candidate to freeze from nerves or get an unexpected mental block.  It's very difficult to objectify what makes a good software engineer. Sometimes someone very intelligent can get hung up on abstractions or theoritical patterns and forget they have deadlines or just not be a good team player.  Sometimes, there's just inescapable subjectivity.

Joel Spolksy

So how do brain teasers help out? Acclaimed tech guru, Joel Spolsky advises to avoid asking them in interviews because they are usually just a case of either the candidate knows it or he doesn't - and not much else.  In my opinion, it can take months to understand someone's technical strengths and weaknesses.  Puzzles can be useful for demostrating how someone approaches problem solving, how they think on their feet and how they communicate ideas.  So yes they do serve a purpose.  But even if they serve no purpose whatsoever other than a bit of fun, that's fine for me.  I love a good puzzle so I really enjoyed this book and for that reason I'd recommend it to anyone who likes to dabble in some cryptic challenges.

References:
1.  Are you smart enough to work at Google