In this presentation he presents quite a number of different ideas that he has learned from his experiences in software development over the years.

These are some of my thoughts and our discussion:

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.

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 the reluctance to change names is complex and highlights some counter-intuitive, or at least irrational behaviour.

Imagining what is going on in people’s heads: If class names don’t map well to their functions, then developers need to have a Map in their heads somewhere. But, this map has to be maintained as things change. And there is no efficient way to communicate changes all at once to all team members. So there is a risk that people end up with different versions of the map.

And then, that ends up being an impediment to talking about the code base. Because every statement you make, might also need to include an update for the function-to-class mapping:
“I had to change the code that twiddles the sprockets.”
“Oh? So you had to make changes to the AccountHelper? I think Tracy is working on that, you’d better let her know.”
“Actually, sprocket twiddling happens in AccountSectionFactory now. I think Tracy is working on AccountExtensions. I know it’s tough to keep it straight…”

Having the smooth conversations is more valuable than being able to change names, so people don’t change the names. That way the conversations don’t have all this mapping update overhead.

But, if class names derive from functions, then you don’t need the Map at all. It’s not arbitrary, it can be derived from the function:

Now there is no synchronisation problem between the team members. Class names can be derived from the function. Map updates aren’t wasting bandwidth in conversations.

This does assume everyone agrees on how to describe particular functions. But the BAs can solve that problem for us by introducing a ubiquitous language. ^_^

This description is an application of an idea called “the tree of talking”. Though I didn’t realize that until I was halfway through typing it up. This link to flickr was the most relevant google result. I can explain it at a whiteboard some time too if you’re interested. http://www.flickr.com/photos/davegray/3292821165/