Robert Martin at NDC

Robert Martin gave 3 talks at NDC, these are my notes.

Clean Code (Functions)

Here Robert Martin gives an interesting talk about the lowest level of program organization; functions.  He starts by showing us a long function in his own project, Fitnesse, and asks the audience what it does.  He then begins taking a critical view of the function, identifying the weakness in the design (it is too long, has train wreck call chaining, nested ifs, boolean flags, mixed levels of abstraction).  After some simple refactoring to extract methods he shows the same function, now significantly reduced in size, it is much easier to deduce the intent of the function.

He champions the use of the Explanatory variable:
bool isTestPage = myPage.containsIgnoreCase(“Test”);
if(isTestPage){ … }

Rather than:
if(myPage.containsIgnoreCase(“Test”)){ … }

Then he lists his Rules of Functions:

  • The first rule of functions: they should be small
  • The second rule of functions: they should be smaller than that
  • Blocks within if statements, while statements, for loops, etc should be one line long
  • …and that line of code will usually be a function call
  • There should be no more than one or maybe two levels of indentation
  • Functions should do one thing
  • Function statements should all be at the same level of abstraction
  • A function should have no more than 3 arguments
  • Output arguments are a code smell
  • Passing a boolean flag into a function is truly awful.  You are by definition doing two things in the function.
  • Side effects are lies.

His philosophy can by summarized as “Extract until you can extract no more”.  Most of the functions will be called from only one place, a departure from the original idea of the function as a reusable code fragment.  Think of a newspaper, where the heading is followed by a summary paragraph, followed by increasing level of detail. This is how he suggests we tackle complexity of software.

He also gave an interesting quote from Ward Cunningham.  Answering the question “What is Clean Code” he replied “You know you are working on clean code when each routine turns out to be pretty much what you expected”.

S.O.L.I.D Principles of Object Oriented Design

On day two Robert Martin gave an afternoon of talks based on his SOLID principles of code.  The first talk was on dependency management.  The second talk was on component principles.

Robert Martin had a good debate with Joel Spolskey (of Joel on Software fame) and Jeff Atwood (of Coding Horror) about the merits and demerits of the SOLID principles.

Dependency Management

He began by talking about how the complexity of software is growing exponentially over time, and how the size of our codebases make change more difficult as they grow.  Change rots our systems, and rotten code is difficult to change.  The problem is that the whole point of software is to change, thats what makes it different from hardware.  So if we can free ourselves from tight coupling and dependencies we should be able to break this trend and make systems that are easy to change.  He then goes on to describe some principles we can use in Object Oriented programming to acheive this by showing a simple program and how it responds to change:

Single Responsibility Principle: A class should only ever have one responsibility, or one reason to change.  So don’t mix business rules, database schemas, output routines, etc. because it will make your design tightly coupled.
Open/Closed Principle: A class should be open for extension, and closed for modification.  This means it should be possible to change the behaviour of a class (via for example polymorphism) without changing existing source code.
Liskov Substitution Principle: Subclasses should behave as expected when referring to the superclass.  i.e. there will be no unexpected side effects of using a subclass as a superclass.
Interface Segregation Principle: He didn’t cover this one, but a cursory google search gives this: “Clients should not be forced to depend upon interfaces that they do not use.”
Dependency Inversion Principle: depend on abstractions/interfaces.  This is the key principle he cites with his code examples to enable software to change.

I highly recommend this talk, it was very interesting and as usual with Robert Martin the presentation was excellently delivered.

Component Principles

In this talk Robert Martin looks at the problem of Component Coupling and describes some approaches we can use to try to get us out of the quagmire.  For the purposes of this talk he offers the following definition of component: “An independently deployable chunk of code”.  By this he means an executable, dll, shared object, jar file, etc.

He proposes a new power law that he has observered during his career:
Every decade shows an order of magnitude increase in codebase size.

Component design has been one of the key reasons that we have been able to build larger and larger systems, but as with all levels of software the devil is in the dependencies.  As dependencies between component grow the coupling causes a dilution of productivity.

The principles of component structure are as follows:

  • The Reuse/Release Equivelency Principle (REP): The smallest thing that can be reused is what should be released.  It should have its own version number.
  • The Common Closure Principle (CCP): A component should not change for different reasons.  See the Single Responsibility Principle above. May conflict with REP.
  • The Common Reuse Principle (CRP): You want to split component A when component A depends on only part of component A.

These principles are linked and can be thought of as triad on which you must make tradeoffs.

The principles of component coupling are:

  • The Acyclic Dependency Principle (ADP): Component dependencies should not form a cyclic graph.
  • The Stable Dependency Principle (SDP): A component should only depend on components that are more stable than itself.  Stable means “hard to change”.
  • The Stable Abstractions Principle (SAP): Should depend on abstract components, equivalent in spirit to the Dependency Inversion Principle.

Interestingly, he proposes a compelling definition for Adult and Teenage components.  An adult component is responsible and does not depend on others, whereas a teenage is irresponsible (changes often) and does depend on others.  You should have a balance of both in a system but should be aware of what each component is.

Clean Practice: Agility and Craftmanship

In his final talk, Robert Martin discusses the process of software development and what it means to be a professional.  This talk seems like a continuation of his keynote the day before but goes into a bit more depth and is much more concrete than earlier.

He covers some basics, like using developing in short iterations.  I suppose there are still projects which are not following some kind of agile methodology, but to deliver this advice at a software conference it seems a little redundant.

Don’t wait for definition: it is better to do something than do nothing.  If you can’t get requirements from a client you should go ahead anyway and start the conversion by delivering software.
Abstract away volatility: protect yourself from things that change by using abstractions.
Decouple from others: use mocks and fakes to be able to test independently from others.
Avoid turgid (cloudy) viscus (thick) architectures: speaks for itself.
Incremental Improvement: have the discipline of continuous improvement to your code.  Clean at every opportunity.
No Grand Redesigns: this is a trap, and rarely works.  It is expensive and risky.  See the previous point.
Don’t Write Bad Code: There is no way to rush and go fast, in software development those are oxymorons.  When you rush software development you will go slower because of poor quality and rework.
Test Driven Development: The argument is over, TDD won.  How can you say you are a professional if you can’t prove your software works?
QA Should Find Nothing: It is not QAs job to find bugs, it is QAs job to prove that there are no bugs.
Avoid Debugging: debugging is a failure, this is what unit testing is for.
Have a definition of done:  you must have a definition of done that is unambiguous.
Test through the right interface:  Don’t test through the GUI unless you are testing the GUI.  It is a bad idea to test functionality through the gui because it makes your gui impossible to change.
Apprenticeship: The best way to teach people to program is to sit down senior engineers with junior engineers and to program together but we don’t.
Use Good Tools: obvious.
Continuous Integration: use a CI server.
Open Office: Isolation is unproductive.  Conversation is key to collaboration.

All this advice boils down to “never be blocked“.  Seems reasonable to me.

Links to Video Streams

Clean Code (Functions)

Dependency Management

Component Principles

Practice: Agility and Craftsmanship


Leave a comment

Filed under Uncategorized

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s