Thinking of ways to measure code readability. How easy is it to read and understand a  method, or class ?

Number of branches in a method ? more branches -> more complex  hence a more complex method  that is hard to read

Split the camel casing of a method/class into words and run some sort of word analysis to check if the words make sense ?

The analysis has to be automated, and run as part of CI ideally..

Today, at work I was treated to a rare opportunity to attend a talk by Martin Fowler. I may or may not get the chance to hear someone who can profoundly inspire developers. with simple( sometimes obvious) nuggets of wisdom, that will make us build better software.

The talk didn't have a specific title, but centred around the theme of software design and how we go about it. His talk mostly focused on how keeping things simple can help build better software. This concept is obvious, but many of us loose sight of it.

look at what has already been done.

Similar problems have already been solved, someone out there knows how to solve it.  This is the basis of all the design patterns that have been collated by Eric Gamma et al and Martin Fowler himself.  Patterns are nothing new, they are not the future. They are practices that have been used in successful software in the past, and we can draw on the lessons learnt during the past 30 (or more)  years of software development.

spread knowledge backward

it's important that older, experienced developers pass on their knowledge to new or less experienced developers. He made an interesting point on how software architects at Thoughtworks pair up with less experienced developers. A good software architect is one who does not have to make any decisions. On a related subject Martin said "burn your architecture document". If the developers have to refer back to a document, it means that they haven't fully absorbed the architecture of the system being built, and there are gaps in their knowledge.

keep things simple, expect and prepare for change

This is what inspired me the most. Software is soft( malleable). It always changes, expect and be ready to change. Importantly be prepared to undo change. Work with what you know, and do not worry about changes that can happen. Postpone decisions till you absolutely need to make them. Organise work into incremental chunks of changes.

There is a lot more I took away from the talk. Might take a while to digest it all :). However these are concepts that are stressed in the books listed below, specially in The Pragmatic Programmer.

If you haven't read any of Martin Fowler's books, I strongly suggest you do so immediately, along with a few other books that will inspire ( and shock you) into being a better developer.

Patterns of Enterprise Application Architecture

Refactoring: Improving the Design of Existing Code

Domain-driven Design: Tackling Complexity in the Heart of Software

The Pragmatic Programmer

Kudos to Jason for organising the talk.