This is the first book that I've read on the iPad's Kindle application and it was a reasonably good reading experience – I particularly like the fact that you can make notes and highlight certain parts of the text.

It's also possible to see which areas of the book other Kindle users have highlighted and you can see your highlights/notes via the Kindle website.

The Review

The sub-title of the book: 'Are you indispensable? How to drive your career and create a remarkable future' didn't really appeal to me all that much but I've found that these types of things are often just for provocation and don't necessarily detract from the message.

As with the other Godin books I've read, he spends a lot of time making his original point and in this one it felt like I'd already agreed with what he was saying for at least 50 pages before we moved onto something else.

Despite that I think there were some good points made in the book. These were some of the more interesting ones for me:

• One of my favourite quotes from the book is the following about fire:
  

  Fire is hot. That’s what it does. If you get burned by fire, you can be annoyed at yourself, but being angry at the fire doesn’t do you much good. And trying to teach the fire a lesson so it won’t be hot next time is certainly not time well spent.

  Our inclination is to give fire a pass, because it’s not human. But human beings are similar, in that they’re not going to change any time soon either.

  One of the things I've noticed over time is that it's very unlikely that the core way a person behaves is likely to change regardless of the feedback that they get from other people.

  Pat touches on this in a post where he points out that we need to be prepared for feedback to not be accepted.

  I don't think this means we should stop giving feedback to people if we think it will help them be more effective but it does seem useful to keep in mind and help us avoid frustration when we can't change a person to behave in the way we'd like them to.

• Godin makes an interesting point about the value of the work that we do:
  

  A day’s work for a day’s pay (work <=> pay). I hate this approach to life. It cheapens us.

  This is exactly the consulting model – billing by the hour or by the day – and although I've come across a couple of alternative approaches I'm not sure that they work better than this model.

  Value based pricing is something which I've read about but it seems to me that there needs to be a certain degree of trust between the two parties for that to work out. The other is risk/reward pricing and I've heard good/bad stories about this approach.

  It seems to me that we'd need to have a situation where both parties were really involved in the long term outcome of the project/system so if one party is only invested for a short % of this time then it's going to be difficult to make it work.

• Shipping is another area he touches on in a way that makes sense to me:
  

  I think the discipline of shipping is essential in the long-term path to becoming indispensable.

  The only purpose of starting is to finish, and while the projects we do are never really finished, they must ship. Shipping means hitting the publish button on your blog, showing a presentation to the sales team, answering the phone, selling the muffins, sending out your references. Shipping is the collision between your work and the outside world.

  While this is just generally applicable, in software terms this would be about the sort of thing that my colleagues Rolf Russell & Andy Duncan cover in their talk 'Rapid and Reliable Releases'.

  I also had an interesting discussion with Jon Spalding about the importance of just getting something out there with respect to the 'Invisible Hand' browser plugin that he's currently working on. Jon pointed out that it's often best to ship and then rollback if there are problems rather than spending a lot of time trying to make sure something is perfect before shipping.

• Godin spends a lot of time pointing out how important human interactions and relationships are and I think this is something that is very important for software delivery teams. One of the most revealing quotes is this:
  

  You might be parroting the words from that negotiation book or the public-speaking training you went to, but every smart person you encounter knows that you’re winging it or putting us on.

  Virtually all of us make our living engaging directly with other people. When the interactions are genuine and transparent, they usually work. When they are artificial or manipulative, they fail.

  I attended a consulting training course when I first started working at ThoughtWorks 4 years ago and I've always found it impossible to actually use any of the ideas because it doesn't feel natural. It's interesting that Godin points out why this is!

Overall this book feels to me like a more general version of Chad Fowler's 'The Passionate Programmer' which is probably a more applicable book for software developers.

This one is still an interesting read although it primarily points out stuff that you probably already knew in a very clear and obvious way.

In this book Ricardo Semler, the CEO of Semco, tells the story of the company and how he helped evolved the organisation into one which is more employee led and embraces ideas such as open & self set salaries while encouraging civil obedience in the workforce as a necessity to alert the organisation to its problems.

These were some of the ideas that I found the most interesting:

• Early on Semler points out that Semco doesn't have a culture of looking busy. He describes how a sales manager spends a lot of his day just reading the newspaper but then as soon as there's a problem for him to handle that's when he earns his salary. Even though this book isn't specifically about systems thinking, the description of this situation suggests to me that they are able to look at the bigger picture at Semco.

  In software teams we can often feel quite guilty if we're not busy but a bit of slack time is often useful for thinking about better ways to do things or to spike out new ideas.

• Semler emphasises the need to have small business units of under 150 people while matches up quite well with research done by Robin Dunbar which indicates that 150 is the 'theoretical cognitive limit to the number of people with whom one can maintain stable social relationships.' Semler also adds that keeping the units small 'keeps them human'.

  I know ThoughtWorks keeps this in mind with respect to our offices and will look to open a new one if the number of people in one is getting close to the 150-200 mark.

• Semco have a culture of what Semler refers to as 'absolute trust' which he suggests is a more natural way. They implemented this at Semco by removing security checks on the gates into/out from the plants.

  He almost then predicts the inevitable question in the reader's mind with the following statement:

  2 or 3% will take advantage of an employer's trust. Is this a valid reason to subject 97% to a ritual of humiliation?

  Have thefts increased or decreased?

  I don't know and I don't care. It's not worth it to me to have a company at which you don't trust the people with whom you work.

  He promotes an approach of common sense amongst his employees, suggesting that 'rules freeze companies inside a glacier; innovation lets them ride sleighs over it'.

  The general idea seems to be that the small details aren't really that important and only serve to distract from the bigger objectives that the company are trying to achieve.

• I was quite surprised to read how strongly Semler recommends job rotation:

  Man is by nature restless. When left too long in one place he will inevitably grow bored, unmotivated, and unproductive. The cure, I believed, was to encourage managers to exchange jobs with one another

  He goes on to point out that this type of rotation forces people to learn new skills which makes them more valuable but also discourages empire building because people don't stay in the same place for too long.

  I think we do this to some extent in the software industry between some roles but probably not as much as we could do. Having said that there is a lot to learn as a developer anyway so perhaps it's not so applicable here.

• Perhaps the most controversial idea in the book is that of transparent/self set salaries. There was initially resistance to the latter idea as cynics believed that a few people would take advantage and award themselves massive pay increases. However, they found that having those salaries public served as a strong disincentive.

  He also identifies the fact that people have a stake in the success of the company as being key for allowing this to work:

  The third reason our people tended to be modest about salaries has to do with self preservation…Our people know salaries account for most of our operating costs, and they think about our budgets when they set them. It's easy to solve a budget problem by eliminating a salary that seems too high, and noone wants to stick out.

• The underlying reason behind why a lot of the ideas Semler implements seem to be about unhiding information as described by the following quote:

  There is power in knowing something someone else doesn't…but when cards are held close to the chest, communication will be faulty and anxieties, misunderstandings, insecurity, and eventually hostility will manifest itself…which is why when we started sharing information at Semco it has such a profound effect. People in the higher echelons could no longer rely on the conventional symbols and had to develop leadership skills and knowledge to inspire respect.

  Spreading responsibility for problem solving across the organisation is another idea Semler strongly encourages and I think this partly explains why it's more fun working in an agile environment.

  Information in general is more accessible and because of that people have more opportunity to solve problems than they otherwise would.

• Semler discusses the need to keep the organisation lean even when times are good which he acknowledges is much more difficult than trying to keep it lean when times are hard! For Semco this involves being careful when hiring people to work on product lines which they knew had a short life span as well as ensuring that they didn't add any unnecessary roles just because sales were strong.

Towards the end of the book Semler suggests that his goal with Semco was to 'make people look forward to coming to work in the morning' which seems like quite a noble objective!

I found it quite interesting that although a lot of these ideas seem a bit radical, they made sense in Semco's context because they were introduced incrementally and only after some other ideas had been introduced which helped smooth the way.

It's certainly an interesting read and the ideas expressed at quite different than what is typical in most organisations.

These are some of my favourite parts:

• Ship it!
  

  If there are minor bugs, ship it as soon you have the core scenarios nailed and ship the bug fixes to web gradually after that. The faster you get the user feedback the better.

  Often on projects I've worked on we've taken the approach that bugs get worked on before new stories which makes sense in a way because it means that we are fixing problems quickly and keeping the quality of the application high.

  In reality what often happens is that low priority bugs just end up not getting looked at but I like the fact that we can choose to make that an explicit approach rather than just allowing it to happen to us.

  Prioritize your bugs (and even ignore some of them)

  Just because you discover a bug in your product, doesn’t mean it’s time to panic. All software has bugs – it’s just a fact of life.

  I find it interesting that there might be more value in getting something out the door and then getting feedback on it rather than spending extra time perfecting it up front.

• Fix Time and Budget, Flex Scope
  

  You have to figure out what’s really important. What’s going to make it into this initial release? This forces a constraint on you which will push you to make tough decisions instead of hemming and hawing.

  From my experience a lot of times we end up implementing features just because that's what was agreed in the initial release plan and there is often a reluctance to change that even if a feature isn't really that useful anymore.

  It becomes even more problematic if we get to the stage where it's not possible to deliver all the features promised in the remaining time so it certainly makes sense to me that in that situation we would look to focus on getting the absolutely essential things in first.

• Choose any enemy
  

  Sometimes the best way to know what your app should be is to know what it shouldn’t be. Figure out your app’s enemy and you’ll shine a light on where you need to go.

  This seems to be a much better idea than just copying the ideas of your competitor which might seem the obvious thing to do if you're working in the same area.

  The problem with that approach of course is that when you do copy you have no actual vision of what you're doing with your application anyway so you'll always be playing catch up.

• Don't overcomplicate the application

  There are a few parts of the book where the authors talk about keeping the application simple and then letting the users play with it:

  The harder we tighten things down, the less room there is for a creative, emergent solution. Whether it’s locking down requirements before they are well understood or prematurely optimizing code, or inventing complex navigation and workflow scenarios before letting end users play with the system, the result is the same: an overly complicated, stupid system instead of a clean, elegant system that harnesses emergence.

  Keep it small. Keep it simple. Let it happen.

  Andrew Hunt, The Pragmatic Programmers

  The users can then decide for us where we need to fill in more details:

  Details reveal themselves as you use what you’re building. You’ll see what needs more attention. You’ll feel what’s missing. You’ll know which potholes to pave over because you’ll keep hitting them. That’s when you need to pay attention, not sooner.

  In particular they suggest that focusing on very specific details about the page layout/colour/wording can be left until later because it will only serve to hinder forward progress if we concentrate on it too early.

• Scaling an application
  

  You don’t have a scaling problem yet

  “Will my app scale when millions of people start using it?”

  Ya know what? Wait until that actually happens.

  On several projects that I've worked on there often seems to be a desire to focus on performance and scaling an application very early on which seems wasteful when we could be focusing on actually building something that has so many users that we need to scale it later on. I think this advice is spot on.

• Write less software

  A common theme throughout the book is that of writing less software to achieve our goals:

  The best designers and the best programmers…are the ones that can determine what just doesn’t matter.

  That’s where the real gains are made.

  Most of the time you spend is wasted on things that just don’t matter. If you can cut out the work and thinking that just don’t matter, you’ll achieve productivity you’ve never imagined.

  Innovation is not about saying yes to everything. It’s about saying NO to all but the most crucial features.

  Throw away customer feature requests – if they're really important then they'll come back anyway

  Don’t worry about tracking and saving each request that comes in. Let your customers be your memory. If it’s really worth remembering, they’ll remind you until you can’t forget.

  The authors ideas around preferences were particularly interesting to me:

  Preferences are also evil because they create more software.

  More options require more code. And there’s all the extra testing and designing you need to do too.

  I hadn't appreciated until recently quite how much complexity we can add to an application by allowing users to play around with the display of information on a screen.

  It seems like a nice feature to have but it would be interesting to see statistics that could tell us what percentage of users actually that type of thing when it's not the core idea of the application.

  I also quite liked the following and I think it's something that we need to do more often on teams:

  Encourage programmers to make counteroffers.You want to hear: “The way you suggested will take 12 hours. But there’s a way I can do it that will only take one hour. It won’t do x but it will do y.” Let the software push back. Tell programmers to fight for what they think is the best way.

• Decisions are temporary so make the call and move on
  

  So don’t do the “paralysis through analysis” thing. That only slows progress and saps morale.

  Instead, value the importance of moving on and moving forward. Get in the rhythm of making decisions. Make a quick, simple call and then go back and change that decision if it doesn’t work out.

  I think a big part of this is getting the mentality that it's fine to make changes after we've 'finished' something. Any other approach doesn't work from my experience.

• Reduce meetings
  

  Meetings usually arise when a concept isn’t clear enough. Instead of resorting to a meeting, try to simplify the concept so you can discuss it quickly via email or im or Campfire.

  I find it interesting that they prefer communicating by email because I've often found that it's not the best communication mechanism since it's really easy to misinterpret what people mean.

  Having said that if we can make concepts clearer and the need for a meeting is an indicator that we need to do that then perhaps we can still meet in person and just make the meeting much shorter.

• Design the interface before you start programming
  

  Too many apps start with a program-first mentality. That’s a bad idea. Programming is the heaviest component of building an app, meaning it’s the most expensive and hardest to change. Instead, start by designing first.

  I've certainly fallen into this trap a lot but I've been trying to follow the outside in approach more strictly recently and so far I'm finding that it reduces the feedback cycle quite substantially which is only a good thing.

• Design for regular, blank, and error states
  

  For each screen, you need to consider three possible states:

  Regular
  The screen people see when everything’s working fine and your app is flush with data.

  Blank
  The screen people see when using the app for the first time, before data is entered.

  Error
  The screen people see when something goes wrong.

  I'd never even though of this at all and I'm certainly guilty of only ever considering applications when all the data is filled in so this is certainly something else to consider.

• Tear down the walls between support and development
  

  In the restaurant business, there’s a world of difference between those working in the kitchen and those out front who deal with customers. It’s important for both sides to understand and empathize with the other. That’s why cooking schools and restaurants will often have chefs work out front as waiters so the kitchen staff can interact with customers and see what it’s actually like on the front lines.

  My colleague Chris Read and some others seem to be trying to close this gap with the devops movement which also has a track at QCon London this week.

  The idea of working in support to see what an application is like from that perspective is something that more experienced colleagues often recommend although I've not done it as yet.

Overall I found this book a really interesting and quick read and although many of the ideas suggested seem like common sense it's strange that we often don't do all of them.

The 37 Signals guys also have a new book coming out in the UK tomorrow titled 'Rework' which sounds like it could be quite a good read as well.

These were some of the parts that particularly stood out for me:

• Introduce the elephant in the room – whatever it is that people are really thinking about, put it out in the open. I think on development teams there is often a distrust of the way that other people write code because it's different to the way that we do. If we can get this out in the open more frequently and agree on a shared approach then it should result in a more consistent code base.
• Get the fundamentals down – Pausch suggests that we need to understand the fundamentals because otherwise the fancy stuff isn't going to work. In Apprenticeship Patterns Ade Oshineye and Dave Hoover suggest that we should 'Study the Classics' which is a similar idea.

  While I think they're certainly right I'm not sure that learning theory before putting it into practice is the most effective way to learn. I think we need to do a bit of both at the same time alternating between the two so that we actually have a frame of reference when we're learning the fundamentals.

• The brick walls are there for a reason – Pausch describes how we'll often come across obstacles stopping or blocking us from what we want to do but that we shouldn't be discouraged, they are there so that we can see how much we really want something. I think this is just generally true and not just related to software development.
• The skill of self assessment – Pausch suggests that we need know what we don't know which I think is perhaps the best advice in the book. We need to recognise our true abilities but also have a sense of our flaws and create feedback loops to allow this to happen.

  My colleague Liz Douglass has come up with the idea of Feedback Frenzies to help create this feedback loop and this is one of the best ideas I've come across for doing this.

• One of my favourite quotes from the book is the following which I believe was originally from Dan Stanford:
  

  Experience is what you get when you didn't get what you wanted

  …

  It's a phrase worth considering at every brick wall we encounter, and at every disappointment. It's also a reminder that failure is not just acceptable, it's often essential.

  I think we can do this much more in the software world. There sometimes seems to be a stigma with identifying things which fail but I think it's really useful for others to learn from mistakes that have been made.

The Last Lecture is one of the best presentations I've had the chance to watch – I'd certainly recommend it.

Paul Butcher offered me a copy of the book to review so I was keen to see whether it was more like 'Debugging' or 'Release It' as Ted Neward suggests.

The Book

Debug It by Paul Butcher

The Review

Much like Krzysztof Kozmic I found that a lot of the ideas early on in the book were similar to what I've been taught by my ThoughtWorks colleagues over the last 3 1/2 years.

I do think it's really good seeing these ideas in words though because it's quite easy to forget about the best way to approach problems in the heat of the moment and the approaches suggested by Paul certainly aren't done everywhere in my experience.

These were some of my favourite parts of the book:

• When chasing a bug Butcher suggests that a useful technique to use is to try and disprove your theory of why the problem has happened. Too often we come up with a theory and just adapt any data to fit our thinking. This is also known as confirmation bias.

  In his talk 'Pimp my architecture' Dan North suggests a similar approach more generally when working out how to tackle any problem. Each person has to take the other person's argument and then fight for that to be used instead. I quite like this idea – certainly something to try out.

• When discussing the need to refactor code as we go along, the author points out that if the code we want to change doesn't have any tests around it then we need to write some to provide us with a safety net.
  

  Remember, however, that refactoring crucially depends upon the support of an extensive suite of automated tests. Without tests, you’re not refactoring. You’re hacking.

  Hamlet D'Arcy makes a similar point but perhaps more forcibly in a really good blog post and Michael Feathers' 'Working Effectively With Legacy Code' covers the topic in much more detail.

• One tip which seems obvious but is still one I've tripped up on many times is to go through the list of changes that we've made before checking in! It's incredibly easy to forget about some seemingly insignificant change that we made before checking it in and perhaps breaking our application unexpectedly.

  Somewhat tied in with this is the idea of checking in small changes more frequently and only changing one thing at a time which I wrote about previously.

• I like that Butcher puts a lot of emphasis on ensuring that we actually know what's going wrong before we attempt to fix anything.
  

  Without first understanding the true root cause of the bug, we are outside the realms of software engineering and delving instead into voodoo programming or programming by coincidence.

  This is particularly true when addressing performance problems where he rightly suggests that we should look to profile the code before making a premature optimisation.

  He also suggests using the debugger so that we can get a good idea about what the code is actually doing when it's running. While I think this is useful I feel that the need to use the debugger in this way frequently might suggest that our code is difficult to reason about which could well be something to address.

• A couple of other cool suggestions are to call on team mates to help us out if we're getting stuck trying to fix a bug and if that's not possible then to either write out the problem or talk to the rubber duck.
  

  If you don’t have someone to play the role of cardboard cutout, all is not necessarily lost. Try scribbling down a narrative of the problem on paper or perhaps composing an email to a friend. The trick is not to censor yourself — just like a writer would.

  I don't think the importance of communicating with team mates can be underestimated and Butcher points out that if we notice a bad pattern in the code than it's no good just going through and changing it everywhere. We need to talk with the rest of the team to decide whether we can get an agreement on the way we'll develop code going forwards.

• The only idea I disagreed with is that of putting assertions into the code which I feel adds clutter to our code even though it makes it fail faster than would otherwise be the case. From my experience if we write good enough unit tests and have good logging in our code then the assertions aren't needed.

In Summary

The book is pretty quick to read at around 200 pages and packs a lot of useful tips into that space. I'd say it's a pretty useful book to keep by your desk to refer to now and then.

The Book

Fundamentals of Object-Oriented Design in UML by Meilir Page-Jones

The Review

I really enjoyed reading this book and I think it's one that I could come back and read again to gain something else from in the future.

Nearly all the mistakes that I've made and seen made with respect to the design of object oriented code are outlined in one form or the other in this book.

The book is split into three sections. The first discusses some fairly basic object oriented concepts, the second covers UML as a notation for describing our designs and the final section goes more deeply into the principles of object-oriented design.

What did I learn?

• Although we don't seem to use UML much these days I was coming to the conclusion while reading those chapters that perhaps UML is useful as a design tool but the aim shouldn't be to come up with a UML diagram, but rather to drive a design in code.

  This is something which Uncle Bob also touched on recently:

  Is TDD a replacement for design?

  No. You still need all your design skills. You still need to know design principles, and design patterns. You should know UML. And, yes, you should create lightweight models of your proposed software designs.

  We actually found on a project I worked on recently that everyone had a different way of diagramming a design and it would have been useful to have a common notation between us. UML is surely the tool to solve that problem.

• I quite like the way that Page-Jones describes the different types of messages that objects can receive:
  • Informative – a message telling an object about something that happened in the past.
  • Interrogative – a message asking an object to reveal something about itself.
  • Imperative – a message telling an object to take some action on itself.

  An interrogative message is effectively a getter whereas the other two are commands being sent to the object. I've not seen the distinction between events which happened in the past and those which are going to happen in the immediate future.

• I've frequently come across the idea of information hiding when it comes to designing objects but Page-Jones introduces the idea of implementation hiding which I think is really neat.

  The idea is that while some information about our object will be viewable to other objects e.g. through attributes/getters, we can still hide the implementation of that information internally so that if we we want to change it in the future then we won't have to change all its clients too.

• I found the concept of the rings of operation really interesting. The idea is that there are some methods on our objects which just make use of other methods on the same object. Those methods wouldn't touch any of the fields of an object directly but would rely on those methods in the inner rings to do so.

  For example if we have a getter on an object to access a field then if other methods on that object want to access that field they should go via the getter instead of accessing the field directly.

  I often find myself avoiding using getters with the hope that if don't increase their usage then it will be easier to get rid of them in the future. This approach would discourage doing that.

• I like the idea of type conformance when it comes to inheritance – we should try to ensure that any sub types adhere to the contract of their parent.

  The other part of this chapter describes 'closed behaviour' – all the operations on any class that we inherit from should obey our class' invariant.

  I think this can be where we go wrong when we write classes which extend a List for example. The API of a List will typically have 'Add' and "Remove' operations but on a lot of the application I work on we only want the 'Add' functionality and not the 'Remove' option. Page Jones suggests that if we want to use inheritance in this situation then we should override methods on the super class to make 'Remove' do nothing.

• I now find that I prefer Page Jones definition of cohesion:
  

  Class cohesion is the measure of interrelatedness of the features (the attributes and operations) located in the external interface of a class

  I'm inclined to believe that we might be able to tell how related the features are by looking at the clients of the class and seeing whether they are all using the class in similar ways.

  He then outlines three signs that we have cohesion problems with a class:

  • Mixed instance cohesion – a class has some features that are undefined for some objects of the class. I find that this typically happens when we try to make a generic data type to cover everything and then try to jam any variations on the type into the same definition. It is typically solved by pulling out another class. This is the worst type of cohesion.
  • Mixed domain cohesion – a class contains an element that directly couples the class with another class that is unrelated domain wise. This typically happens when we mix infrastructure code into our domain code.
  • Mixed role cohesion – a class contains an element that couples it with an unrelated class in the same domain. I think this is the most typical type of cohesion that I've seen and the main problem is that we end up with classes which have multiple roles which makes them difficult to change.

In Summary

There's way more in this book than I could ever hope to cover here but these are some of the interesting bits that stood out from this reading of it. I'm pretty sure that I'll come back to this one in the future.

While reading the book I had the feeling that some of the ideas are quite similar to those in Domain Driven Design and since this book was published it contributes to my belief that a lot of DDD is covered by just doing OOP well.

Overall this is a really good book, worth reading.

Zen Mind, Beginner's Mind by Shunryu Suzuki

The Review

I first came across the actual term beginner's mind when reading through the 'Wear The White Belt' chapter of Apprenticeship Patterns although it was often mentioned to me on one of the first projects I did at ThoughtWorks a couple of years ago that people liked teaching me things because I just took the information in pretty much without questioning.

I find nowadays that I analyse what people tell me way a lot more and then compare it against what I already know to see if it adds to my understanding. In a way this is useful but sometimes prevents me fully understanding ideas since I have already judged them.

I started researching beginner's mind a bit to see if there was anything written on the state of mind required to maximise learning and this was the book that kept being mentioned so I decided to get a copy of it.

It is fundamentally a book on Zen and a lot of the stuff around that area didn't make a lot of sense to me but I think there were some general ideas which can be applied to learning in general.

What did I learn?

• One of the early chapters sets the message for the book with the following quote:
  

  In the beginner's mind there are many possibilities. In the experts there are few.

  Straight away it gets to the point which I think describes the problem that we have in software development once we've done a few projects and accumulated a set of ideas of the best way to deliver software – we often stick to those ideas and aren't open to the idea of better ideas being out there.

  On the other hand as Fred Brooks points out there is no silver bullet so perhaps this also explains why there is often skepticism when new ideas are described since its quite likely that potential negative points of these approaches have either not been described or not yet discovered.

• The author raises some interesting ideas around how to get the best out of people by suggesting that the best way to do this is to let them do what they want but to watch them. Although he then went out to reference this back as a metaphor for controlling our own thoughts I was reminded of the Netflix culture slide show which I came across lately in terms of how they give employees freedom but expect them to act in the organisation's best interest rather than expecting employees to follow a lot of rules.
• One thing I really liked was the emphasis on listening to what someone says 'without having your own idea [in mind]…forgot what you have in your mind and just listen to what he says'. I think one problem we can run into when listening to other people is that we extract the bits of what they say which fit in with what we believe – something known as the confirmation bias.

  I actually found an old post of mine which lists some mistakes we commonly make when listening to others speak. It makes quite interesting reading.

  Another quote from the book sums up a more useful approach:

  See things as they are, observe things as they are, let everything go as it goes

• He goes on to suggest that we should have no negative or positive feelings towards what someone says to us and that we should give up our preconceived ideas and subjective opinions which I didn't think made much sense in the software development game since a lot of what we do is about assessing the merits of different approaches.

  The beginner's mind entry on the C2 wiki makes more sense by describing Ward Cunningham's approach:

  You can generally tell when you're dealing with someone who really knows their stuff by the amount of reference they make to the way it has always been done. Folk like our own WardCunningham seem able to ditch all that stuff and approach each problem as if it were completely new and they had never done anything like it before.

  Then, when they have a solution, they'll either recognize it as a Pattern in the standard lexicon, and leverage readymade tools, or not. But they never come in armed for bear when all the customer needs to catch is clams.

  It seems like we only initially need to have an empty mind while we are taking in the new information and then we can make use of the knowledge that we already have later on.

• The author suggests that 'when you do something just to do it should be your purpose' which seems somewhat similar to the idea of focusing on the process in Agile instead of always on the outcome of what we're doing.

  While a result focus can be helpful I often notice that important things like the quality of what we're making get dropped by the wayside if we focus too much just on completion.

  I do think there is some need to focus on whether what we're doing is actually improving us (although the book advises against this) and I recently came across Chad Fowler's idea of always asking 'Am I better than yesterday?'.

• It is pointed out then when learning zaizen we cannot expect rapid progress but instead that we will progress little by little which I think is pretty much the same in software development.

  With nearly all skills a lot of practice is needed – as Talent is Overrated points out – we don't just become an overnight sensation but need to work our way through the Dreyfus Model for each skill gradually improving our level.

In Summary

Although this book is about Zen I still found some interesting ideas about learning and I guess its always interesting to read something a bit different.

I'd be interested in knowing if there was a book that covered beginner's mind purely from a learning point of view instead of Zen if anyone knows of any titles!

Brownfield Application Development in .NET by Kyle Baley and Donald Belcham

The Review

I asked to be sent this book to review by Manning as I was quite intrigued to see how well it would complement Michael Feather's Working Effectively with Legacy Code, the other book I'm aware of which covers approaches to dealing with non green field applications.

What did I learn?

• The authors provide a brief description of the two different approaches to unit testing – state based and behaviour based – I'm currently in favour of the latter approach and Martin Fowler has a well known article which covers pretty much anything you'd want to know about this topic area.
• I really like the section of the book which talks about 'Zero Defect Count', whereby the highest priority should be to fix any defects that are found in work done previously rather than racing ahead onto the next new piece of functionality:
  

  Developers are geared towards driving to work on, and complete, new features and tasks. The result is that defect resolution subconsciously takes a back seat in a developer’s mind.

  I think this is quite difficult to achieve when the team is getting pressure to complete new features but then again it will take longer to fix defects if we leave them until later since we need to regain the context around them which is more fresh in our mind the earlier we fix them.

• Another cool idea is that of time boxing efforts at fixing technical debt in the code base – that way we spend a certain amount of time fixing one area and when the time's up we stop. I think this will work well as an approach as often when trying to fix code we can either get into the mindset of not fixing anything at all because it will take too long to do so or ending up shaving the yak in an attempt to fix a particularly problematic area of code.
• I like the definition of abstraction that the authors give:
  

  From the perspective of object- oriented programming, it is the method in which we simplify a complex “thing”, like an object, a set of objects, or a set of services.

  I often end up over complicating code in an attempt to create 'abstractions' but by this definition I'm not really abstracting since I'm not simplifying but complicating! This seems like a useful definition to keep in mind when looking to make changes to code.

• Maintainability of code is something which is seriously undervalued – I think it's very important to write your code in such a way that the next person who works with it can actually understand what's going on. The authors have a fantastic quote from Perl Best Practices:
  

  Always code as if the guy who ends up maintaining your code is a violent psychopath who knows where you live.

  Writing code that is easy for the next person to understand is much harder than I would expect it to be although on teams which pair programmed frequently I've found the code easier to understand. I recently read a blog post by Jaibeer Malik where he claims that it is harder to read code than to write code which I think is certainly true in some cases.

• There is a discussion of some of the design patterns and whether or not we should explicitly call out their use in our code, the suggestion being that we should only do so if it makes our intent clearer.
• While describing out how to refactor some code to loosen its dependencies it's pointed out that when the responsibilities of a class are a bit fuzzy the name of the class will probably be quite fuzzy too – it seems like this would server as quite a useful indicator for refactoring code to the single responsibility principle. The authors also suggest trying not to append the suffix 'Service' to classes since it tends to be a very overloaded term and a lot of the time doesn't add much value to our code.
• It is constantly pointed out how important it is to do refactoring in small steps so that we don't break the rest of our code and to allow us to get rapid feedback on whether the refactoring is actually working or not. This is something that we've practiced in coding dojos and Kent mentions it as being one of his tools when dealing with code – I've certainly found that the overall time is much less when doing small step refactorings than trying to do everything in one go.

  I'm quite interested in trying out an idea called 'Bowling Scorecards' which my former colleague Bernardo Heynemann wrote about – the idea to have a card which has a certain number of squares, each square reprsenting a task that needs to be done. These are then crossed off as members of the team do them.

• An interesting point which is made when talking about how to refactor data access code is to try and make sure that we are getting all the data from a single entry point – this is something which I noticed on a recent project where we were cluttering the controller with two calls to different repositories to retrieve some data when it probably could have been encapsulated into a single call.
• Although they are talking specifically about poor encapsulation in data access layers, I think the following section about this applies to anywhere in our code base where we expose the inner workings of classes by failing to encapsulate properly:
  

  Poor encapsulation will lead to the code changes requiring what is known as the Shotgun Effect. Instead of being able to make one change, the code will require you to make changes in a number of scattered places, similar to how the pellets of a shotgun hit a target. The cost of performing this type of change quickly becomes prohibitive and you will see developers pushing to not have to make changes where this will occur.

• The creation of an anti corruption layer to shield us from 3rd party dependency changes is suggested and I think this is absolutely vital otherwise whenever there is a change in the 3rd party code our code breaks all over the place. The authors also adeptly point out:
  

  The reality is that when you rely on another company's web service, you are ultimately at their mercy. It's the nature of third-party dependencies. You don't have control over them.

  Even if we do recognise that we are completely reliant on a 3rd party service for our model I think there is still a need for an anti corruption layer even if it is very thin to protect us from changes.

  The authors also describe run time and compile time 3rd party dependencies – I think it's preferable if we can have compile time dependencies since this gives us much quicker feedback and this is an approach we used on a recent project I worked on by making use of generated classes to interact with a SOAP service rather than using WCF message attributes which only provided us feedback at runtime.

In Summary

This book starts off with the very basics of any software development project covering things such as version control, continuous integration servers, automated testing and so on but it gets into some quite interesting areas later on which I think are applicable to any project and not necessarily just 'brownfield' ones.

There is a lot of useful advice about making use of abstractions to protect the code against change both from internal and external dependencies and I particularly like the fact that the are code examples showing the progression of the code through each of the refactoring ideas suggested by the authors.

Definitely worth reading although if you've been working on any type of agile projects then you're probably better off skim reading the first half of the book but paying more attention to the second half.

Real World Functional Programming by Tomas Petricek with Jon Skeet (corresponding website)

The Review

I decided to read this book after being somewhat inspired to learn more about functional programming after talking with Phil about his experiences learning Clojure. I'm currently working on a .NET project so it seemed to make sense that F# was the language I picked to learn.

What did I learn?

• I've worked with C# 3.0 since around July 2008 so I had a bit of experience using some of the functional features in C# before picking up this book. I therefore found it very interesting to read about the history of lambda and the different functional languages and how they came into being. Having this as an opening chapter was a nice way to introduce the functional approach to programming.
• Immutable state is one of the key ideas in functional programming – this reminded me of a Joe Armstrong video I watched last year where he spoke of his reduced need to use a debugger when coding Erlang due to the fact that there was only one place where state could have been set rather than several as is the case with a more imperative approach. We have been trying to code with immutable state in mind in our coding dojos and while it takes a bit more thinking up front, the code is much easier to read when written that way.
• Separating the operations from the data is important for allowing us to write code that can be parallelised, focusing on what to do to the data rather than how to do it. Sadek Drobi has a nice illustration of what he calls mosquito programming vs functional programming on page 14 of the slides of his QCon presentation. It describes this idea quite nicely.
• A cool technique that Phil taught me when reading language related books is to have the PDF of the book on one side of the screen and the REPL (in this case F# interactive) on the other side so that you can try out the examples in real time. The book encourages this approach and all the examples follow on from previous ones which I think works quite well for gradually introducing concepts.
• Functions are types in functional programming – I have had a bit of exposure to this idea with Funcs in C# but partial function application is certainly a new concept to me. I can certainly see the value in this although it took me a while to get used to the idea. I am intrigued as to where we should use a functional approach and where an OO approach when working in C#. I think both have a place in well written code.
• F#'s implicit static typing is one of my favourite things about the language – you get safety at compile time but you don't waste a lot of code writing in type information that the compiler should be able to work out for you. It has the strongest type inference of any language that I've worked with and I thought it was quite nice that it was able to work stuff out for me instead of me having to type it all out.
• I really like the idea of option types which I first learnt about from the book. Having the ability to explicitly define when a query hasn't worked is far superior to having to do null checks in our code or the various strategies we use to get around this.
• I thought it was cool that in the early chapters the focus with the F# code is to provide examples that you can just get running straight away instead of having to worry about the need to structure your code in a maintainable way. After I had a reasonable grasp of this then the chapter about using record types to structure code in an OO way come up. I still prefer the C# style of structuring code in objects – it just feels more natural to me at the moment and manages the complexity more easily. It is quite easy to switch between the two styles using features like member augmentation so I think it's probably possible to mix the two styles quite easily.
• We can use modules to make F# functions which don't fit onto any class available from C# code. The code is not as clean as if we were writing just for it to be used by other F# code but it's not too bad:

  module Tests =                                               
      let WithIncome (f:Func<_, _>) client =                  
          { client with Income = f.Invoke(client.Income) }

  We can then call this in our C# code like so:

  Tests.WithIncome(income => income + 5000, client);

  Dave Cameron has written more about this.

• Although I studied data structures at university I don't really pay a great deal of attention to them in terms of performance normally so it was interesting to see the massive performance hit that you take when appending a value to the end of an F# list compared to adding it to the beginning. F# uses linked lists so if we want to add something to the end then there is a lot of recursion involved to do that which is quite costly. In terms of big O notation we go from O(N) where N is the number of elements to append to O(N*M) in terms of performance.
• Chapter 13 is about parallel processing of data for which I found I needed to download the Microsoft Parallel Extensions to .NET Framework 3.5, June 2008 Community Technology Preview and then add a reference to 'C:\Program Files\Microsoft Parallel Extensions Jun08 CTP\System.Threading.dll' in order to make use of those features.
• The author provides a nice introduction to continuations and how you can make use of them in F# by using continuation passing style. I'm intrigued as to how we can make use of these in our code – we do a bit already by making use of callbacks which get fired at a later point in our code – but from what I've read it sounds like we should be able to do even more especially when writing web applications.
• Asynchronous workflows are also made very accessible in this book – I had previously struggled a bit with them but the author covers the various API methods available to you and then explains what is going on behind the syntactic sugar that F# provides. I have made some use of these in the little twitter appication that I've been working on now and again.

In Summary

I really enjoyed reading this book – it's my first real foray into the world of functional programming since university and I think I understand the functional approach to programming much better than I did back then from reading this book.

It takes an approach of introducing various functional programming concepts before showing examples of where that concept might come in useful when coding. It's also particularly useful that examples are shown in C# and F# as this made it much easier for me to understand what the F# code was doing by comparing it with the code in a more familiar language.

I'd certainly recommend this to any .NET developers curious about learning how to apply ideas derived from functional programming to their C# code and indeed to any developers looking to start out learning about functional programming.

97 Things Every Software Architect Should Know by Richard Monson-Haefel

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.