Mark Needham

Thoughts on Software Development

Book Club: Design Sense (Michael Feathers)

with 2 comments

In our latest technical book club we discussed a presentation given at the Norwegian Developers Conference by Michael Feathers titled ‘Design Sense‘.

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.

    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 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.

There’s a lot of other ideas in this talk as well but these are some of the ones that made me think the most.

Be Sociable, Share!

Written by Mark Needham

September 30th, 2009 at 12:42 am

Posted in Book Club

Tagged with

  • Chris Desmarais

    On that name is provisional thing…

    If a class has changed jobs, and needs a new name. You’re probably missing something and there’s some more refactoring required.

    Hacking new functionality onto an existing concept until the original concept is gone… is hacking and you’re probably going to screw something up.

    Split the class, abstract out an interface, add a layer of abstraction are all more likely to be long term successful solutions.

    Retire a class and rebuild before renaming.

  • http://intwoplacesatonce.com Dave Cameron

    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:

    public void string FindClassByFunction(Function function) {
    return function.GetType().Name;
    }

    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/