· software-development books book-review

97 Things Every Software Architect Should Know: Book Review

The Book

The Review

My colleague Erik Doernenburg mentioned that he had written a couple of chapters in this book a while ago and there was a copy of the book in the ThoughtWorks office so I thought I’d take a look.

I’m far from being an architect but since their decisions affect what I do I was intrigued to see what they should be doing.

The contributions in the book are also available on the 97 things wiki.

What did I learn?

This book contains a series of short essays by software architects, 97 in total, so clearly there is a lot to be learnt from this book. I’ll just cover some of the ones I found most interesting.

  • The first chapter in the book talks of the need to not put your resume ahead of the requirements and instead choose the right technology for the customer rather than the one that you want to use. Later on Greg Nyberg talks about how good ideas kill projects due to them getting out of hand and taking up much more time than expected to implement and affecting far more of the code than you would think. The suggestion therefore seems to be that we shouldn’t upgrade frameworks and should be cautious about introducing technologies into our project. At face value this seems to make sense but it somewhat limits our ability to improve in my opinion. If we always choose the technology based on what we currently know then how will we know when something better comes along. I much prefer the idea of trying out several solution early on (an idea that Erik Doernenburg mentions in 'Try before choosing' using lean’s idea of concurrent set based engineering. Experimentation is very important early on in a project although of course we must eventually be looking to choose the best solution and go with that at the last responsible moment.

  • Another one that really stood out for me is 'Simplicity Before Generality, Use Before Reuse' written by Kevin Hennery. He speaks of how we often use general purpose infrastructure code/class libraries which don’t actually help us solve our specific problem. It’s better to derive the generality of a solution later on having originally designed for what we need them for in the first place. Joe Walnes' XStream framework is often pointed out as being a library which was developed in this way - he only put in the features that he needed rather than trying to think how people might want to use it and by doing so actually did cover the way that most people would use it.

  • I think my favourite essay in the book is 'Don’t Be Clever' by Eben Hewitt where he talks of the importance of being 'as dumb as you possibly can and still create the appropriate design'. He goes on to add:

    More developers can implement and maintain dumb solutions. In dumb solutions, each component can only do one thing. They will take less time to create, and less time to change later.

    It’s so easy to make clever design decisions but when there are other people on a team that need to work with these designs it is in fact pointless to be clever and creating something simple that everyone will be able to work with is a much better approach. Dave Anderson also talks about the importance of designing our code so that it’s easy for someone from a different team to work with especially if they have to make production fixes. The need for the code to be obvious, testable, correct and traceable are pointed out as being key.

  • Another one which I really liked is 'The Business vs The Angry Architect' which talks about the need to listen to what the business are saying instead of always waiting to have our say and display our superior knowledge. My favourite quote from this chapter is:

    Remember; when you’re talking you can only hear something you already know. Don’t ever start thinking you’re so smart that no one else has something valuable to say. ... Don’t allow yourself to become a disgruntled genius that spends all of your time trying to impress others by making witty, condescending statements about how poorly the company is run. They won’t be impressed.

    This is certainly something that anyone in a software team can apply not only architects. Certainly I have learnt that it’s important to accept some decisions instead of constantly pointing out how wrong they are, something which Dan North also points out in his 'Pimp My Architecture' talk.

  • I really like Timothy High’s idea of 'Recording Your Rationale' where he suggests keeping track of all the trade offs being made so that we know in the future why certain decisions were made. This ties in quite nicely with Dan North’s idea of the project shaman who tells the stories of the project and why different decisions were made. Mark Richards also talks about the need to communicate clearly with the developers on the team and keep them informed about the big picture and the like and Timothy High goes on to talk about the importance of recording any assumptions that we make. On every project I’ve worked on we have recorded assumptions related to the order of stories and the approach we are likely to take during estimation sessions and it certainly makes it easier to explain decisions in the future. Dave Quick suggests that we could also record potential risks on projects until they are no longer a risk. They can be prioritised and reviewed when there is new information. I quite like this idea as it puts the information out in the open rather than sweeping it under the carpet.

  • Paul W. Homer talks of the benefit of sharing our knowledge and experiences, an idea that I absolutely agree with and I think can be valuable within teams as well as within the industry. He points out that explaining our ideas to others helps us find the weaknesses in what we are saying - I agree, I find I learn most when trying to teach things to other people.

  • Einar Landre’s essay about how the architect’s focus is around the boundaries and interfaces is another interesting one - I think this is the place where the messiest code ends up being so it makes sense that you would have the strongest person technically in the team involved. Creating these boundaries is certainly essential from my experience. The author talks about making use of Domain Driven Design concepts such as bounded contexts and context mapping to handle the complexity around these areas. Keith Braithwaite also talks about the value of having multiple overlapping representations instead of trying to have one representation for the whole system which seems along the same lines as the DDD approach.

  • Scott Mcphee and Burkhardt Hufnagel both talk about the importance of paying back technical debt before it causes us problems. Scott covers it more from the angle of correcting incorrect decisions as soon as we can while Burk comes at this more from the angle of making changes the correct way later on if we can’t do the first time we make them. I think this is something that we often forget to do and it’s not immediately painful so we think we’ve got away with it until a few months later we notice how truly difficult it is to make any changes at all and then it’s really hard to recover the code to a good state.

  • Jeremey Mayer makes a very astute observation about reuse of code - developers need to know that code is there to reuse otherwise they will just write the functionality that they need themselves. He also notes that developers tend to prefer to solve problems themselves rather than ask for help. Dan Bergh Johnsson also noted at QCon that developers will only wait 30 seconds to try and find a piece of code that they need before writing it themselves.

In Summary

I enjoyed reading this book and there is plenty more in this book than just what I’ve mentioned - I was mainly interested in the architecture advice which affects me as a developer but there’s also advice which doesn’t apply so much to me at the moment which is probably more interesting to architects.

  • LinkedIn
  • Tumblr
  • Reddit
  • Google+
  • Pinterest
  • Pocket