I find one of the most applicable mantras in software development is Bob Sutton’s idea that we should have strong opinions weakly held.

The idea as I understand it is that we shouldn’t sit on the fence but instead have an opinion that we research thoroughly and are prepared to back up. However, we shouldn’t become too attached to those opinions but instead be prepared to listen to alternative points of view and take those on where they prove more useful than our previous opinions.

I think there are a couple of reasons why it applies quite nicely to software development.

The first is that it doesn’t really matter if you’re 'wrong' and it’s quite rare that something you do is completely wrong - normally there might just be a way of doing something that you didn’t think of previously or a technique that you didn’t know about.

For example, it’s fine to throw away code if someone shows you a better way to do something.

In this case you are expressing your opinion (through code) about the way that you think a problem should be solved and if someone shows a different way then we can at least allow them to show us their way and then decide whether or not we like it better rather than becoming defensive that there could be another way to solve the same problem.

This seems quite closely linked to the idea of beginner’s mind and the 'one true solution' anti pattern.

The former is about having an open mind when studying a subject much like you do when you are studying something for the first time. This was an idea I came across when reading the 'Wear the White Belt' entry of Apprenticeship Patterns.

The latter seems to manifest itself when we don’t explicitly consider the trade offs that always rear their head when making decisions in the world of software development and remain convinced that our solution to a problem is the only one that could possibly work.

I also read another interesting post which described a situation where a team threw away working code because it no longer made sense to keep it around since it didn’t add value.

I can’t remember working on a project where we threw away functional code in that way but it is true that having code which doesn’t add value is a burden so I can certainly see how this would have been a good decision.

The other reason I think strong opinions weakly held makes sense is that so often an approach only really makes sense within a given context and then in another context we might do something completely different.

I came across a great example of this recently on my project when we came to the realisation that creating a completely separate domain model to that defined in the service layer we interact with was probably not such a good idea and that we would probably be better off just conforming to the service layer’s model of the system.

I was fairly convinced for a long time that this wasn’t the right thing to do but in this situation we don’t have access to the business to drive out a more accurate model and the piece of the system that we are working on probably wouldn’t derive a great deal of value from doing this anyway.

Therefore my opinion, which perhaps would hold in another context, didn’t really make sense here so I’ve adapted it and in the process made it more useful to me.

With both of these examples I had reasons for why I thought the approach I was taking was the best one and I was able to discuss these before realising that there was a better way and therefore changed my opinion to adopt this new knowledge.

These are just a couple of examples of me changing opinions based on being shown a different/better way and I’m sure there will be many more occasions when this happens in the future, it’s just the nature of software development.