Michael Feathers at NDC

michael feathersI admit it – I’m a Michael Feathers fanboi.  His book, Working Effectively with Legacy Code was a lifeline to me so it was great to see him at the Norwegian Developers Conference.  He gave four talks at NDC, these are my notes.

Seven Blind Alleys in Software Design

I saw Michael Feathers give 4 talks at NDC.  He started his talks with Seven Blind Alleys in Software Design.  Here he identified the common failures that the software industry has repeated throughout its history in the hope that we can avoid them in the future.

  • Programming in Pictures.  Here he bashes the Idea that if only we could diagram the problem the solution would be simple.  Examples are Model Driven Architecture and Executable UML.  His argument is that there is an irreducible complexity in software and that there has never been a successful implementation, so we should look for real systems to avoid the snake oil salesman.
  • Meta-programming.  The idea of configurable systems, where the code manipulates code.  Good for flexibility but bad for understandability. Often the hidden motivation is a fear of changing the code.  Examples are Ruby (Active Record) and Java reflection.
  • The Ultimate Abstraction.  Trying to find an grand unifying concept at the heart of your system (think “item”, “message”, “agenda”, etc).  Examples are the Chandler project, covered in depth in the book Dreaming in Code.
  • The Perfect Taxonomy.  Trying to create a unified definition for a concept (e.g. Account) across domains (think bank, insurance, etc).  Fails at the differences.  Language is ambiguous, software shouldn’t be so you shouldn’t try to use a general taxonomy which differs in details.
  • Modelling the Real World.  Simply trying to translate nouns from the problem domain into system classes.  Often when translating the problem domain into software you have to create classes which aren’t in the real world model.  “Why would you want to model the real world, that’s where the problems are.”  An example is the Square-Rectangle problem: which should inherit from which?
  • Code Generation.  Code generation can de-skill development and hints at a crisis of ambition.  The Pragmatic Programmers contradict this and advise that you should generate code if at all possible, a view that I generally agree with.
  • Natural Languages.  Domain Specific Languages and testing tools such as Behaviour Driven Development.

There is a famous CS quote from Butler Lampson (or David Wheeler, depending on who you choose to believe) which says that “All problems in computer science can be solved by another level of indirection”.  I think with this talk Michael Feathers proposes a corollary “All projects in Computer Science can be destroyed by an unnecessary additional level of indirection”…

Working Effectively with Legacy Code

This talk is really an introduction to Unit Testing for existing code.  Michael Feathers has written the book on this topic, so it was interesting to hear him present it, with real code.  The main thing to take away from his approach is to be conservative with the changes you make to existing code, and use dependency breaking techniques to enable you to get code under test.

Most applications are glued together (think singletons, internal instantiation, dependency on concrete classes, external resources) and this tight coupling can make it difficult to test your code.  A good place to start is to create a test class and test the class instantiation.  This will make it obvious what the class dependencies are and is an important first step.

The next step is to create a test that asserts a stupid expected value.  Then when the test fails the test framework will tell you what you actually get and you can paste this into your assertion.  This way you can be sure that before you start changing the system you know if you deviate from existing functionality.  He calls this type of test a Characterization Test.

He also described two nice approaches for dealing with C++ classes, Sprout Method and Sprout Class.  These techniques can help you get your code under test without changing the header files by clever file inclusion.

Functional Thinking for Object Oriented Designers

In this talk Michael Feathers give a brief introduction to Functional Programming from the perspective of OO designers.  Functional Programming seems to be the new hotness for software development (and may be the solution to mutiprocessing) so there was quite a lot of interest for this talk.  He went through the basics of the Ruby collect methods, some simple Haskell examples, Partial Functions and Lazy Evaluation.  He also showed how some standard design patterns (Command, Template, Visitor) look in a functional language which highlighted the strengths of the paradigm.

Also discussed were the hybrid model of development (where you use both OO and functional in your software) and the friction that can cause.  He suggests that the root cause of the friction is that good Object Oriented design follows the principle “Tell, don’t ask” whereas good functional design follows the principle “Ask”.  A possible solution is to use OO for the high level in “push” model, and use functional programming for low level functionality in a “pull” model.  These hybrid models are still in their infancy so I think we have a lot yet to understand before we can generalize good practices.

This was an interesting talk, but for those that have some experience with functional programming it was a little shallow.

Design Sense – Deep Lessons in Software Design

The final talk from Michael Feathers covered the ideas which underly the principles and patterns of software development and are not as well known today as they should be.

  • You can’t make software more correct by adding redundancy.
  • Protection (private, protected) is solving a social problem, not a technical one.
  • There are no requirements, there is only design.  The user experience is an important aspect of development and is much more valuable than laundry list requirements.
  • Names are provisional (think Rename Class refactoring).
  • Physical Architecture shapes Logical Architecture (think Twitter, MapReduce).
  • Conways Law: “Organisations which design systems …. are constrained to produce designs which are copies of the communications structures of these organizations”.
  • Feature teams lead to the tragedy of the commons.
  • You can’t finesse away error handling with good design.
  • Error policy is as important as the main line.  Every system should have a policy (fail fast or never crash).
  • Null checks are a code smell.
  • Logging is a first class citizen.  It should be seen as part of the problem domain and you should have a strategy designed into your system.
  • Databases are good for more than string data.  Can have huge object hierarchies in your memory otherwise.
  • Objects want to be asynchronous (think Alan Kay “objects are cells”, seen in Erlang)

Links to Video Streams

Watch out! The streaming doesn’t seem to work for me on Window with firefox.  I can see it on IE, or on the mac with Firefox or Safari.
Seven Blind Alleys in Software Design
Working Effectively with Legacy Code
Functional Programming for Object Oriented Designers
Design Sense – Deep Lessons in Software Design


Leave a comment

Filed under Uncategorized

Leave a Reply

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

WordPress.com Logo

You are commenting using your WordPress.com 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