Ayende @ Rahien

My name is Oren Eini
Founder of Hibernating Rhinos LTD and RavenDB.
You can reach me by phone or email:


+972 52-548-6969

, @ Q c

Posts: 6,128 | Comments: 45,551

filter by tags archive

JAOOWorking Effectively with Legacy Code 2 – Michael Feathers

time to read 3 min | 425 words

I have a tremendous amount of respect to Michael Feathers, so it is a no brainer to see his presentation.

Michael is talking about why Global Variables are not evil. We already have global state in the application, removing it is bad/impossible. Avoiding global variables leads to very deep argument passing chains, where something needs an object and it passed through dozens of objects that just pass it down. We already have the notions on how to test systems using globals (Singletons). He also talks about Repository Hubs & Factory Hubs – which provide the scope for the usage of a global variable.

  • Refactor toward explicit seams, do not rely on accidental seams, make them explicit.
  • Test Setup == Coupling, excessive setup == excessive coupling.
  • Slow tests indicate insufficient granularity of coupling <- I am not sure that I agree with, see my previous posts about testing for why.
  • It is often easier to mock outward interfaces than inward interfaces (try to avoid mocking stuff that return data)
  • One of the hardest things in legacy code is making a change and not knowing what it is affecting. Functional programming makes it easier, because of immutability.
  • Seams in a functional languages are harder. You parameterize functions in order to get those seams.
  • TUF – Test Unfriendly Feature – IO, database, long computation
  • TUC – Test Unfriendly Construct – static method, ctor, singleton
  • Never Hide a TUF within a TUC
  • No Lie principal – Code should never lie to you. Ways that code can lie:
    • Dynamically replacing code in the source
    • Addition isn’t a problem
    • System behavior should be “what I see in the code + something else”, never “what I see minus something else”
    • Weaving & aspects
    • Impact on inheritance
  • The Fallacy of Restricted Languages
  • You want to rewrite if the architecture itself is bad, if you have issues in making changes rapidly, it is time for refactor the rough edges out.

More posts in "JAOO" series:

  1. (06 Oct 2010) The Go Programming Language
  2. (20 Oct 2009) More on Evolving the Key/Value Programming Model to a Higher Level from Billy Newport
  3. (07 Oct 2009) OR/M += 2
  4. (05 Oct 2009) Evolving the Key/Value Programming Model to a Higher Level
  5. (05 Oct 2009) Working Effectively with Legacy Code 2 – Michael Feathers



So many mistakes, so little text.

Slow down there champ. Re-read what you're writing to make sure you've gotten your thoughts down lest your readers have to struggle through debugging your text themselves :(

Ayende Rahien


That is what you get when I try to both write & listen at the same time.

Feel free to skip the JAOO posts, if you don't like them.


I think aspects are great for non-business behavior like logging, caching, authorization, validation, etc...

Can you elaborate on this?

Ayende Rahien

Not my session, but I think he meant that it is easy to have things more complex if you do complex things in the aspects.

BL, for example.

Colin Jack

Out of interest what are Repository Hubs & Factory Hubs?

Grimace of Despair

Offtopic and related to Ben's remark: I think Ayende needs a big disclaimer just below the site banner:

*** WARNING: I use my blog to twitter

I mean: other people put much time in composing well-thought posts, while Ayende practically thinks them up in his blog. A bit like what Twitter is actually meant for. Minutes after a post, he can come up with his own rebuttal. From time to time you see people not used to this reacting on a post and sometimes even quite heavily. I mean: I probably spent more time putting this reaction down than Ayende spent making this post.

Comment preview

Comments have been closed on this topic.


  1. The worker pattern - 2 hours from now

There are posts all the way to May 30, 2016


  1. The design of RavenDB 4.0 (14):
    26 May 2016 - The client side
  2. RavenDB 3.5 whirl wind tour (14):
    25 May 2016 - Got anything to declare, ya smuggler?
  3. Tasks for the new comer (2):
    15 Apr 2016 - Quartz.NET with RavenDB
  4. Code through the looking glass (5):
    18 Mar 2016 - And a linear search to rule them
  5. Find the bug (8):
    29 Feb 2016 - When you can't rely on your own identity
View all series


Main feed Feed Stats
Comments feed   Comments Feed Stats