I found the idea of financial based decisions particularly interesting - I’ve often had situations when developing software where there are trade offs to make and it would have been much easier to make them if we had a dollar value associated with each potential solution. I’m not sure how willing the business would be to expose this information to the development team though.

There is mention of setting up incentives at one level higher than you would normally expect - Nicor is cited as an example of a company which does this. For example, a plant manager would be incentivised based on the performance of all the plants rather than just his plant. The thinking here is to try and get everyone thinking about the bigger picture. I’m not convinced that financial incentives work particularly effectively for motivating people to achieve goals although several colleagues disagree with me in this regard. For me making sure that everyone believes in the project and its goals is more important.

The role of the master developer is recognised as being key for ensuring the success of development teams. I’m not sure if this role maps directly with that of a Technical Lead, to me it seems to cover more responsibilities on the business side than a Tech Lead would typically have. It doesn’t seem to quite describe the Software Craftsmanship idea of a Master either. Toyota’s idea of a Chief Engineer most closely describes a role which sounds like that of the master developer.

There is a lot of emphasis placed on concurrent engineering - taking a breadth first approach to development over a depth first one. This would involve spiking lots of different ideas before working out which one is the most appropriate. While I have done this on agile projects, the way it is described in the book suggests considering even more options for longer periods of time. The key is to ensure collaboration with the customer and to design change tolerant systems.

The way to ensure systems are tolerant to change is to keep things which change together - in the same layer or module for example. Creating code which has high cohesion and separation makes change easy when it eventually needs to happen.

I liked the idea of considering development as a cycle of experiments with a test at the end of each cycle. As is pointed out, we are going to test our code anyway so it makes sense to capture the test so that we can reuse it. When written well tests can be very useful as documentation but as Jimmy Bogard points out, there are some important steps that we need to follow to ensure that our tests achieve this goal.

I found the reasoning around why we try to maintain a sustainable pace quite interesting. It mostly focused around the need to maintain some slack in the system so that if emergencies come up then we are able to respond to these. This would clearly not be the case if we already had our team working flat out. This seems to me to also be a case of non optimising locally at the expense of the whole system.

The ideas around product integrity were new to me but quite intriguing - perceived integrity is about the value of a product in the mind of the customer, while conceptual integrity is about ensuring that different parts of the system work together in a consistent way. The Chief Engineer/Master Developer would probably spend a lot of time ensuring this actually happens.

Towards the end of the book the authors talk about systems thinking and how we need to ensure that we solve the right problem correctly otherwise we will just end up creating even more problems. Reading this reminded me a lot of The Logic of Failure which talks of the difficulties humans have envisaging the effects of the actions they take will have on the world. The 5 Whys was suggested as a way to get to the root cause of a problem rather than focusing on the symptoms.

I like the ideas around not locally optimising systems by trying to allocate defects to individual developers for example. In this case we should look to create information measurements rather than performance measurements. I am still intrigued as to whether there are any types of measurements that we can use to evaluate the performance of developers but at the moment I’m not convinced that there are.

My favourite quote came from the last chapter of the book which described instructions for using the material contained within the book. 'Think Big, Act Small, Fail Fast, Learn Rapidly' - a good motto to follow I think.