The first part of the presentation talks about method size and Feathers observes that there seems to be a power law with relation to the size of methods in code bases - i.e. there are a lot of small methods and fewer large methods but there will always be some a very small number of massive methods. Dave suggested that perhaps this is related to Benford’s Law which describes exponential growth processes. I wonder whether this observation is somehow linked to the broken window theory whereby if a method is large then it is likley to increase in size since it probably already has some problems so it doesn’t seem so bad to throw some more code into the method. With small methods this temptation might not exist. From what I’ve noticed the messiest methods tend to be around the edges of the code base where we are integrating with other systems - in these cases there is usually a lot of mapping logic going on so perhaps the benefit of extracting small methods here is not as great as in other parts of the code base.

I really like the observation that protection mechanisms in languages are used to solve a social problem rather than a technical problem. For example if we don’t want a certain class to be used by another team then we might ensure that it isn’t accessible to them by ensuring it’s not public or if we dont' want certain methods on a class to be called outside that class then we’d make those methods private. I think this is a reasonable approach to take to protect us from although it was pointed out that in some languages, like Python, methods are publically accessible by default and the idea when using private methods is to make it difficult to access them from outside the class but not impossible. I guess this is the same with most languages as you could use some sort of metaprogramming to gain access to whatever you want if needs be. There’s an interesting post on the Python mailing list which talks through http://groups.google.com/group/comp.lang.python/msg/b977ed1312e10b21.[some of the benefits of using languages which don’t impose too much control over what you’re trying to do].

The observation that names are provisional is something that I’ve noticed quite a lot recently. Feathers points out that we are often reluctant to change the names of classes even if the responsibility of that class has completely changed since it was originally created. I’ve noticed this a lot on projects I’ve worked on and I wonder if this happens because we become used to certain types being in the code and there would be a period of adjustment for everyone in the team while getting used to the new names - it might also ruin the mental models that people have of the system. Having said that I think it’s better to have names which describe what that class is actually doing now rather than keeping an old name which is no longer relevant.

I quite like the idea that the physical architecture of a system can shape the logical architecture and that often we end up with a technological solution looking for a problem. I’m not sure if it’s completely related but one way that this might happen is that in an environment where we structure a team in layers it’s possible that certain functionality will end up being implemented by the team that can turn it around the quickest rather than being implemented in the layer where it might best logically belong. He also mentions Conway’s law which suggests "...organizations which design systems ... are constrained to produce designs which are copies of the communication structures of these organizations." - that seems to link in quite closely with the above ideas.

Amongst the other ideas suggested I quite liked the idea that requirements are just design decisions but that they are product design decisions rather than technical design decisions. I like this as it opens up the idea that requirements aren’t set in stone and that we can work with them to come up with solutions that actually solve business problems instead of 'design by laundry list' as Feathers coins it. I think his recent post about the boutique software shop explains these ideas in more detail.