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:

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:

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.