Well, a couple of reasons. First, I like to write posts in Markdown using Vim. For the last year or so I’ve been converting posts to HTML, piping the output to clipboard, and pasting it into Blogger’s web UI. Switching to a platform that supports Markdown makes that a little simpler. I’ve also never really like the Blogger/Picasa Web image integration thing, so running my own blog means I can dump images wherever I want to and embed away. I also wanted to experiment a bit more with different layouts, but rather than relying on Blogger’s templating system, I wanted to work with straight HTML and CSS (well, via SASS). This would also buy me separation between layout, content, and platform.

If all this sounds a bit tenuous to you then you are probably right. I think all this is justification for me just wanting a change after half a decade on the same platform.

And so you are now reading a static site generated by Octopress, hosted on Heroku. I’ve imported everything over from Blogger and for the most part have kept the same links to avoid breaking stuff. If you find anything amiss or have any problems reading on your browser / feed / device please let me know and I’ll do my best to fix it up (yes, I know the font is large :)).

Thanks to Paul for good naturedly goading me into finally flicking over to Octopress and for helping me out with some questions; Troy, OJ and Tarn for their advice; and Thomas for putting up with all sorts of inane questions I bombarded him with over email and IM.

And finally, thanks to Blogger for an enjoyable 5 years! So long, and thanks for all the posts and fish and stuff. :)

This idea started to dawn on me while I was in Joshua Kerievsky’s Refactoring workshop at YOW 2011. We were going through refactoring exercises, but trying to take extremely small steps to keep the tests green. The final goal could be achieved fairly easily by moving a few chunks of code around while keeping the tests broken for a while, but I really enjoyed the challenge of finding small steps that would keep the tests passing all the way to the final state.

This was further reinforced at Tony’s excellent Functional Programming workshop, where we spent quite a bit of time trying to fit together various functions (and partial applications of them) according to their type signatures. I thoroughly enjoyed this process, despite really struggling to get the solutions much of the time. I also realised I get an extra kick out of these puzzles when there is an element of elegance or simplicity to the way these pieces fit together. For example, implementing map with folds rather than recursion and pattern matching.

I think identifying what you enjoy about programming (or any activity really) can be an important part of maintaining motivation, and improving productivity and creativity as a result. I’m going to put this idea to the test by trying to break down problems in ways that I can use approaches I enjoy, and see if that helps me get better results, both in terms of solution and my happiness and enthusiasm.

This knowledge also helps me better understand some of my weaknesses. I have spent a lot of time over the years trying to piece together various patterns and practices to try and find a process I can continually apply to create great software. In other words, trying to solve the puzzle of how to develop software. My propensity to approach things as puzzles has probably led me astray here, as the unlikelihood of a silver bullet for software development has been demonstrated time and time again. Recognising this, I’ll try be more careful to make sure I’m solving the right problems, and not just inventing problems to puzzle-solve (although that can be educational as well, provided it’s deliberate).

So, what is it about programming you enjoy? Can you use that knowledge to improve the way you work?

Why not QWERTY?

I type reasonably well with QWERTY: normally between 90 - 110 wpm. I started doing some practice to try and improve my accuracy and technique and noticed a few things. First, my right hand tended to drift all over the keyboard (away from the home position), which would result in me sometimes getting lost and making a mistake. A mistake at 110 wpm means typing around 10 characters in the second it takes you to realise it. Backing out those characters, correcting the mistake, correcting your positioning, and continuing gives your typing speed a pretty big hit and is quite frustrating.

Second, my hands had to do all sorts of gymnastics while typing. Common English character combinations like ‘st’, ‘ion’, ‘ce’, ‘ed’ require some big shifts that take you away from the home position (slow and error prone), or require using the same finger for consecutive characters (slow and encourages shortcuts which shift your position).

Third, QWERTY is left-hand biased (at least for English). This can become quite fatiguing. There are also words like ‘minimum’ and the frequently-typed ‘sweaterdresses’ (pointed out on the Colemak site) that rely on a single hand; again, quite fatiguing.

I started to wonder if improving my QWERTY was worthwhile. Maybe I should try an alternate keyboard layout like Dvorak, which was meant to address many of these comfort and accuracy issues (my main goal), and also improve overall speed (a distant second goal).

Why Colemak?

It was around this time I saw @TheColonial mention something about the Colemak layout. I’d never heard of it, but in trying to research what it was I found some promising signs. Colemak was designed to be efficient and ergonomic by keeping commonly used keys on the home row and on the strongest fingers (check out the heatmaps for Colemak et al.), as well as being easy to learn by not deviating too far from QWERTY (the entire bottom left hand is unchanged from QWERTY, which means common shortcuts like Ctrl+Z/X/C/V are unchanged).

If you’ve ever experienced programmer hands, you’ll appreciate why it is important to look after yourself and avoid RSI. I happened across PAT or JK’s keyboard layout analyser, plugged in a few pieces of code and blog posts, and found that, had I typed these using Colemak instead of QWERTY, my fingers would have moved in the order of 50% less to type the same text. Figures like 192m for QWERTY, 97m for Colemak were not uncommon. It also tended to beat out Dvorak. How could anyone interested in efficiency not try that out?

Three weeks with Colemak

I started out doing Colemak exercises with aTypeTrainerForMac. Largely due to its commonalities with QWERTY, the layout itself was quite easy to learn. I had the key positions memorised by the end of the first day, but using it effectively was another matter entirely.

No matter how well I knew the individual keys, I found my brain wanted to think about typing a whole word or pattern at a time. I could start typing the first few characters in Colemak, get to a familiar pattern like ‘ion’, and my brain would leap ahead and get me to complete the word (incorrectly) in QWERTY. Getting my reason to fight these reflexes was very uncomfortable, but at the same time a fascinating insight into how the brain works.

After 1 week of fairly intense practice, I could type steadily at 20 wpm with Colemak, but my QWERTY had dropped a bit to 80.

Shortly after that (with the help of autocomplete) I was able to use Colemak pretty effectively. After three weeks of almost exclusive use I could type between 40-50 wpm and it felt very comfortable. My technique and accuracy were improving.

It was then I found my QWERTY was down to 15 wpm. That is not a typo; a measly 15 wpm. I was completely unable to use a standard keyboard.

Return of the QWERTY

I was a few days away from attending a Code Retreat in Brisbane, and was really concerned about being able to pair with people when I couldn’t type properly. I decided to jump back into QWERTY full time. It took a solid day, but after being completely useless for an hour or so the reflexes started to come back. By the end of the day I was back to 90 wpm (provided I didn’t think too hard about it :)). Surprisingly I could still type ~30 wpm on Colemak.

One thing that really surprised me is how clumsy QWERTY felt to me. I could feel the added strain on my fingers, wrists and shoulders due to the increased movement. Accuracy seemed to come much easier with Colemak, although that could have been a product of how I had trained myself up on all the characters, rather than on real text. I also really started to notice the bad touch typing habits I had formed with QWERTY, like leaving the home row and using wrong fingers to hit keys due to the key positions of many words.

Current state

I’m really undecided on how to proceed from here. One one hand Colemak really seems a lot more comfortable, and I’m pretty confident I could get up to comparable levels of speed with it.

On the other hand, almost every other keyboard in the English-speaking world uses QWERTY. It’s obviously going to take me a bit of work to maintain proficiency with both QWERTY and Colemak. The alternative, being unable to use most other computers effectively, is very unappealing. If I was only ever going to use my own computer I’d almost definitely stick with Colemak, but as I do a lot of pair programming it really comes down to exactly how much effort it’s going to take to be bi-typal.

If we end up getting QIDO for Colemak it may help for pair programming, but I’m still concerned about being stuck at some random computer and being unable to use it.

My other concern is that my perceived increase in comfort with Colemak is at half the speed of my QWERTY typing. I’m not sure whether Colemak would still be comfortable once I hit 100 wpm, or whether I would get the same discomfort as I do with QWERTY.

So there you have it; a bit of a non-conclusion. Colemak seems to have a lot of things going for it, but it’s hard to recommend it in the face of the ubiquity of QWERTY and with only anecdotal evidence of it’s ergonomic benefits (and there’s some counter-anecdotes too). It’s definitely an interesting experiment to try, just for some insight in to how your brain works with typing, but unless you only use your own hardware I’d suggest keeping up speed on QWERTY as well.

As for me, I think I’ll try and develop both QWERTY and Colemak in parallel for a while and see what happens.

I’m currently battling some driver signing issues. We have some incomplete documentation from a previous occasion we’ve been through a related problem, but no one remembers the exact steps used. Because this previous occasion was reasonably considered a one-off, it was never automated. If it had been, it would now provide reliable, repeatable, unambiguously documented steps for getting me out of my current jam. Even if not an exact match for my current requirements, having a working example I could use as a basis to work from would be invaluable.

This has made me think that it is probably worth automating a whole bunch of tasks I hadn’t previously considered due to their infrequent nature. What better documentation of a procedure than working, executable steps? Sure, there may be a need for accompanying rationale, but given a blind choice between a Word/wiki document and something that actually runs and works, I’m picking the latter.

Don’t mock types you don’t own

I’ve written about this before, and I still think it is good advice. Test down to your lowest level of abstraction, then integration / contract / acceptance test over the boundary. By mocking a type you don’t own that dependency starts bleeding in to your code and pushing your own abstractions in potentially unhelpful ways. You’re also not really testing much; unless you also have good contract tests then checking you’ve called a specific external method is not going to tell you much about whether your code does what it needs to.

Contrived example: say I was faking out Math.Round() (let’s pretend it’s an instance method or you are using a framework that can mock statics via the profiler API):

[Test]
public void Calculate_with_rounding() {
    math.Round(2.5).Returns(3); //Fake math.Round
    var subject = new Calculation(math);

    Assert.AreEqual(subject.AddAndRound(1, 1.5), 3);
}

Perfectly reasonable? Well, except for the fact .NET uses banker’s rounding and rounds 2.5 to 2 (and 1.5 to 2 for that matter). If you were using Python (which rounds away from 0), you would have been spot on. If you care about the rounding method, you’ve now got a bug.

If something as simple as rounding can trip us up, imagine what we could do if we start mocking ORM or ADO.NET calls.

Try to avoid mocks in acceptance tests

In my experience this tends to result in too much behaviour being pushed into the mocks. My first preference is to use real pieces, second is to hand-code fakes that have enough logic to work as required, and convenience methods to help tests configure them appropriately. As per "don’t mock types you don’t own", it is also a good idea to test your fakes match the real behaviour.

Learn mocking before a mocking framework

I’ve often heard developers new to automated testing say things like "I really need to learn (Rhino Mocks | Moq | Mocking Framework X)". I think this is the wrong emphasis; before learning a framework for creating test doubles it’s important to understand how test doubles work and how to use them.

For me, a great way to learn was to hand-roll all my fake objects for my tests to act as required. Manually stubbing out values and/or recording calls gave me a good understanding of the different types of test doubles (mocks, spies, stubs etc.) and how they work. Once this got old (very quickly) it was fairly simple to take the behaviour I knew how to hand-code and translate that into the syntax required by a mocking framework. It just became a matter of automating what I was already doing. (It also helped me understand common difficulties like trying to mock non-virtual members.)

Don’t explictly test intermediate steps or inconsequential details

If we assert on details of an implementation we tend to get tight coupling and brittle tests. An example I have seen fairly frequently is:

[Test]
public void Should_get_the_widget_from_the_factory() {
    var factory = MockRepository.GenerateMock<IWidgetFactory>();
    var subject = new Foo(factory);
    subject.DoStuff();
    factory.AssertWasCalled(x => x.GetWidget());
}

[Test]
public void Should_turn_the_widget() {
    var widget = MockRepository.GenerateMock<IWidget>();
    var factory = MockRepository.GenerateStub<IWidgetFactory>();
    factory.Stub(x => x.GetWidget()).Return(widget);
    var subject = new Foo(factory);
    subject.DoStuff();
    widget.AssertWasCalled(x => x.Turn());
}

Here the first test is a completely redundant. The second test covers that entire code path (how else could the widget from the factory get turned, if the subject did not call the factory?). Now you could argue that you prefer the extra, explicit specification the first test provides, to which I’d respond that I don’t think it’s worth the pain from the additional friction it causes when you want to change this implementation detail.

Besides, what do we really care about for our subject? That it uses a factory? Or that it turns the widget? Focus on how you want the object to behave, not how it implements that behaviour.

This approach can help lead us to better abstractions, as we start identifying roles and responsibilities separately from implementation details. And it will definitely make your code easier to change without the friction of over-specified tests.

Mock interaction with the contract, not the specific implementation

On a highly related point, the aim of abstraction is decoupling from the implementation. If we are configuring our test doubles with lots of behaviour that our unit tests are relying on then our object is coupled to that particular implementation, not to a contract of behaviour or a role. For an abstraction to be effective we should be able to drop in a completely new implementation that fulfils the required role. This is not the case if we need to set up a test double’s method to call another dependency and return some rearrangement of the result. If we’re relying on that in our test then our abstraction has failed.

Sometimes you just get stuck with having to perform a callback from a stub, but in general if you are pushing behaviour into your mock, re-think the design or consider using a hand-coded fake before you go contorting your mocking framework.

Beware over-abstraction

It is quite easy to churn out layers of useless abstractions when using mock frameworks. Abstractions have a cost. Feedback from tests is great, but pay close attention to SOLID and the rules of simple design and call out to meaningful abstractions, rather than putting in a dependency just for testing. I wrote some guidelines on abstractions a while back that I don’t entirely disagree with yet.

Some unanswered questions

Mocks vs. stubs, tell vs. ask.

I’ve tended to prefer stubs over mocks (stubbing out the results of calls rather than checking they were received), as per the widget factory example above. This flies in the face of the "Tell, don’t ask" principle, which recommends we don’t ask a collaborator for some state and act on the result, but instead give the collaborator the state it needs from us and tell it what to do with it. This seems to suggest I should be using mocks (checking received calls) a whole lot more than I stub them out.

Avoiding "Yet Another Factory"

If an object news up something, our unit test will typically have almost no ability to affect that object. If we want to check our subject news up a view model and calls Activate() on it, we have no way of asserting this was done without exposing IsActivated and relying on that implementation detail. Leaky abstraction. Bad.

One solution is injecting a factory into our object. We can stub out what this returns, make it return another test double, and then check it received the Activate() call. Just introduce a factory. Yet another factory. Searching through files matching *Factory becomes an exercise akin to reading War and Peace. And they’re generally not even real factories! They don’t choose a particular implementation, they are just a glorified wrapper over a single constructor.

Sure, I sometimes try to ease my conscience by injecting a factory method as a Func<T> which my IoC container helps me with. But deep down I know its still YAF, and a small part of me dies.

I’m hoping choosing "better" abstractions will help me with this, but I’ve had limited success to date.

Interface explosion

C# seems to make it difficult to do testing without using interfaces. And so I end up pulling out yet another interface that will never see another implementation. I’ve heard Shannon refer to them as "the new header files". Every class has its interface documented in its header/interface file. It’s easy to say just choose better abstractions where the interface can be reused, but this is still something I struggle with.

Mocking in dynamic languages

This post has been written primarily from the perspective of static languages; I not sure how much (if any) applies to dynamic languages. From my limited experience testing and mocking seem to be done quite differently in languages like Ruby and Python. I’m keen to learn more about how mocking is done in these languages and see how much can help me improve how I test.

End of transmission

This has been a brain dump of my current opinions about mocking. If you agree, disagree, and/or can help me with some of my unanswered questions, please leave a comment.

Now if you’ll excuse me, I’m off to code up yet another factory…

We had a branch checked out with 2 new commits on it, and we wanted to squash it into a single commit using git rebase -i (basecommit). This would start the normal interactive rebase, then get into a loop of printing the following error to console:

mv: cannot move '.git/rebase-merge/git-rebase-todo.new' to '.git/rebase-merge/git-rebase.todo'

Looking at the .git/rebase-merge folder, I could see the git-rebase-todo.new file getting repeatedly created, then deleted. This was happening on two different machines.

Some googling lead me to this post which suggested a virus checker may be locking the file.

Sure enough, turning off Microsoft Security Essentials’ Real-time protection, doing the rebase, then turning it back on again, resolved the problem. I’ve never had this problem before so must have just gotten “lucky” with this particular file matching some property the virus checker was looking for.

I guess this is probably worth trying whenever getting strange file IO errors from any software ported to Windows.

This is often quite embarrassing when you realise the previous author was you, but this isn’t the only reason to stop the practice of flaming the authors of rotten code.

Yes, this post is basically a rehash of Andrew’s post, but as it resonated with me I felt compelled to write down my perspective on the topic. His is concise and beautifully written, but mine briefly teases SharePoint, so take your pick. :D

The situation

You open the code. It’s worse than you thought. Your face falls as you flick through the files you need to change, and see one or more of the following:

• Classes with thousands of lines.
• Methods with thousands of lines.
• Nested ifs so deep you need to scroll horizontally to find the end of the arrow.
• Constructors with 17 arguments.
• Regions.
• No trace of automated testing. Or of even having been manually tested.
• Code that only works due to some obscure side-effects.
• Code that only works on Tuesdays.
• Liberal sprinklings of Thread.Sleep.
• Object Oriented code where all object members are static.
• No.respect_for.the_law().of.demeter()
• SharePoint involved somewhere.
• Incredibly clever code featuring an abstract factory pattern to produce strategies which are injected into commands applied with double dispatch using the visitor pattern, proxying through to WCF calls batched into units of work and persisted using an EF entity data model. You can’t help but think this is overkill to print FizzBuzz.

The initial reaction

• WTF!?!?
• No seriously; WTF?!!?!?
• What were they thinking?
• What an unprofessional jerk!
• How do they sleep at night?!?!
• I’ve got to post this to twitter. Everyone will get a good laugh at this.
• Oh, and I’ll blog it! There’s another couple of hundred people to pour scorn and ridicule on this deserving schmuck!
• Even better, I’m posting this to thedailywtf.com!

Stop! Hammertime!

What exactly are we doing here? We’re all puffed up with self-righteous indignation, but what is this vehement response going to accomplish? Shame an incompetent person out of programming, thereby ridding the glorious profession of software development of one of those rare dullards that somehow slip into the ranks of the brilliant, intellectual master-craftsmen and women that dominate the industry? (In case it isn’t clear, that sentence carries a <sarcasm/> tag :P).

Probably not. All we’re doing is stroking our own egos, delighting in someone else screwing up for a change, and further fostering the culture of competitiveness, elitism and macho-attitudes that seem to keep popping up in our industry.

Sure, short-term you may feel better for venting, but adding to the bile on the internet is a bit like peeing in the dam that supplies your own drinking water.

So what could we do instead?

Consider the context

Let’s take a deep breath, then start thinking about why this code stinks. It is important to realise that people are generally trying to do good work. There are probably valid reasons the code you are currently staring at seems wrong, and most of them probably have nothing to do with trying to spite you.

• The author is inexperienced.
• The author does not have experience with that particular problem.
• The author is trying a new approach in an attempt to learn.
• The author doesn’t know about a language feature, pattern, or project convention.
• The author was working to an insane deadline that would cost the company millions if the feature wasn’t out the door in 33 minutes.
• The author was actually confronted with worse code, and did substantial tidy up of a whole bunch of classes and extracted the most ugly bit to a place where it could be refactored later (i.e. where you currently need to modify ;)). The reason you are not currently fighting another 3 fires is because of the work they did.
• The author knew the code wasn’t perfect, but it wasn’t obvious at the time how else to factor it.
• The author just seperated from their long term partner, they have a parent in hospital, their car was smashed by an uninsured driver, their bank just increase its mortgage rate and their pet just died in a tragic canoeing accident. They had trouble concentrating on the code they wrote that week.
• The author implemented a bunch of awesome classes, and this one.
• The author wrote the code in a way that was perfect at the time, it’s just that times have changed.
• The code is actually really good. We just don’t see the beauty of it.
• The author made a mistake. You may remember making one or two of these yourself in your younger days.
• The author was forced at gunpoint to write the code by a rogue PM who was also holding the author’s family hostage, dangling them precariously over a vat of potent hydrochloric acid while screaming “add another responsibility to the class or they all get it! Add more regions and superfluous comments! And CLOSE THAT CLASS FOR EXTENSION!!! DO IT!!!1!”

None of this means the author is a bad person, and yet us programmers seem to take perverse delight in opening some code and sniggering “WTF?!!? What were they thinking?” while firing up our favourite blame tool. Maybe it just makes us feel better about all the cruddy code we’ve written?

Opportunities

Instead of dwelling on the negatives, let’s look at the opportunities the code has given us to do some more constructive things than suggested by our initial reactions.

• If this is public code, we could contact the author, thank them for being brave enough to share the code in the first place, and constructively suggest alternate approaches, explaining the rationale for doing so and being careful to keep the person and the code separate (e.g. favour “this class could use a factory to create this instance” or “we could use a factory…” over “you shouldn’t create this here, use a factory”. This helps get past people’s natural tendency to become defensive, and prevents you from slipping into flame mode.)
• If you work with the person, maybe consider how collective ownership applies, and think about how the team can improve things in future.
• If you can see how the code ended up in its present state and what to do about it, take the general concepts (not the personal attack) and blog that, post it to a programming mailing list, conduct a brownbag session at work, present the general principles at your local usergroup, talk at a conference, get on a podcast, start a podcast. Teach it. Educate. Play a small but valuable part in lifting the community and advancing the practice of programming.
• Think about how APIs or patterns could change or be used to prevent the problem. Release an open source project that makes getting it right easy and obvious (as well as an explanation of why this approach works).
• Practice giving criticism in a constructive, respectful way. This is a skill worth developing.
• Recognise that there is no perfect, tech debt-free solution, and think up of lots of ways to fix the problems you see in the code. This will help you to improve both your coding and your perspective. Combine this with aforementioned blogging, presenting, teaching etc.
• Encourage the author. Programming is hard; praising anything good about the code and encouraging them to try improvements can give them more confidence to tackle future problems more creatively. It’s amazing what being freed from the fear of failure can do.
• We could, hmm, I dunno, maybe FIX THE DARN CODE AND MOVE ON WITH OUR LIVES!!! ;)

Why bother?

Because programming culture seems filled with large egos, worthless competitiveness, negativity, and cults around celebrities which discourage both creative thinking and challenges to the status quo. And yet we also have many examples of selflessness and generosity: people pouring hundreds of hours into OSS projects, donating their time to usergroups and mailing lists, and blogging stuff they learn so that others may benefit. Let’s spend more time on these positives within the dev community. By focusing on the opportunities finding “bad” code gives us, I believe we can get a community where:

• People can ask honest questions without being told to “RTFM n00b”.
• People spend more time discussing different approaches than defending previous ones.
• People can post sample code or OSS projects without being ripped apart and mocked, but instead given constructive advice and congratulations for having the guts to risk failing in public.
• All people can contribute; not just the loudest, most extroverted, most confident personalities. A more diverse group of people will provide more diverse ideas and innovations.
• Failure starts to be considered a wonderful thing, as even a single failure is an opportunity for many people to learn and improve as developers.

Please leave your flames and ad hominem attacks in the comments. ;)

The first reason I’m posting anything about monads at all is that I watched one of Robert “Uncle Bob” Martin’s entertaining NDC 2011 talks titled “WTF is a monad” (video available from the NDC site). I’m unsure how approximated or mathematically correct he was intending the presentation to be, but I found it really interesting and was able to implement something I can only hope was vaguely monadic based on my interpretation of the information he presented. So I thought I’d share it with you in case you could correct me (it should go without saying, but any mistakes here are mine and have nothing to do with Bob or his presentation). Worst case is it gets you interested enough to look into the topic and find out all the stuff I got wrong. (Was that alright OJ? ;))

The second reason is that I like writing words like monad, monadic, and monoid because for a brief, shining moment it makes me feel like a real computer scientist. This moment generally comes crashing down as soon as I realise I have no idea what any of these terms mean, but it is a good couple of milliseconds. :)

Did I mention I don’t know what I’m talking about? For this post especially I mean. Yes? Good, you should be safe to read on then…

Something something monad something

As far as I can gather, a monad is a structure that will let you use functions that take arguments of a certain type, and apply it to values from an another type (I’ll call this the monadic type, but I could be misusing the term). We need to be able to map back and forth between these types. Bob roughly approximates a monad to an adapter; a monad is a way of adapting one type to another.

It is the form of this adapter that makes it a monad. A monad can be expressed as two functions: the unit function, normally called return or result, that takes an argument of the original type and returns the monadic type; and a bind function that takes the monadic type and a function that works on original types. (Technically monads should also obey the monad laws. I’m sure I’ve missed other important points about them too, but let’s run with this for now.)

This structure has a few useful properties, mainly to do with being able to chain a sequence of functions that take arguments of the original type, then apply arguments of the monadic type to that chain. I think.

A dot monad?

Uncle Bob’s first example was using a monad to manipulate a dots type using functions that normally work with integers. The dots type is simply a representation of an integer using ‘.’ characters, so 5 maps to ‘…..’ and back again. We’d like to be able to be able to use dots with standard integer operations like add, so that ‘..’ + ‘…’ gives ‘…..’.

Let’s look at an example in Python:

class DotMonad:
    def result(self, i):
        return '.' * i
    def bind(self, dots, f):
        return f(len(dots))

Here our result function just translates integers (i) into dots. The bind function takes some dots and a function f that takes an integer. First it converts dots to integers (using the length of the string of dots) then calls f using the result.

This means that if we have an add function which takes integers, we can use our monad to adapt that function to take dots.

# Integer add function
def add(a, b):
    return a+b

# Monadic add function for dots
def addM(dotsA, dotsB):
    m = DotMonad()
    return m.bind(dotsA, 
        lambda a: m.bind(dotsB, 
        lambda b: m.result(a+b)
        )
    )

I’ve used a and b as the plain integer types, and dotsA and dotsB to represent our monadic dots type. We can now call addM('..', '...') and get '.....'.

So how’s this work? Well remember that bind takes a dot for a first argument, and calls the function provided as a second argument after converting the dot to an int. The function we provide will be called with dotsA converted to integer a, then recursively call bind to convert dotsB in the same way. The last function in the chain is to the monad’s result method which will convert the result of a+b back to dots.

Let’s expand out and trace through the addM('..', '...') example to make sure we’ve got a handle on this:

return m.bind(dotsA,    # dotsA is '..', which is converted to int and passed to fn in 2nd arg
    lambda a:           # bind calls function with a = len('..'), which is 2 
        m.bind(dotsB,   # dotsB is '...', which is converted to int and passed to fn in 2nd arg
    lambda b:           # 2nd bind calls function with b = len('...'), which is 3 
        m.result(a+b)   # a+b is 2+3=5. m.result converts this back to '.....'
)

I think this is called lifting the add (+) function to work with our monad.

Lifting functions using monads

So we’ve now got a version of the basic integer add function that can work with our monadic dots type. But we’d like to be able to apply all integer functions to work with dots. In fact, we can generalise our addM function from before to lift any function which takes two arguments using a monad that can bind to that function’s argument type .

def liftm(m, op):
    return lambda a,b: m.bind(a,
            lambda ax: m.bind(b,
            lambda bx: m.result(op(ax, bx))
            )
    )

This is pretty much identical to our addM function, but we can now do some neat stuff. Let’s import some standard Python operators and dot-erise them:

import operator

addM = liftm(DotMonad(), operator.add)
subM = liftm(DotMonad(), operator.sub)
divM = liftm(DotMonad(), operator.div)
mulM = liftm(DotMonad(), operator.mul)

#Interactive python session
>>> addM('..', '.')
'...'
>>> subM('....', '...')
'.'
>>> divM(mulM('..', '...'), subM('...', '.'))
'...'

Should we try again? Maybe…

Let’s try another monad (again, from one Bob showed in his talk). This time we’re going to try and represent a type that can either have or be missing a value as a monadic type. So something very similar to .NET’s nullable types, Nullable<T>. The difference with the monadic form is that, because of the way we chain sequences of bind operations, we can actually perform operations involving missing values without throwing null reference exceptions everywhere.

class MaybeMonad:
    def result(self, x):
        return x
    def bind(self, maybe, f):
        if (maybe is None):
            return None
        else:
            return f(maybe)

Here our result function just returns whatever value it is given. If it has a value it will return that value; otherwise it will return None (Python’s null or nil value).

Now we can lift our standard operators to work with our Maybe type:

>>> addm = liftm(MaybeMonad(), operator.add)
>>> mulm = liftm(MaybeMonad(), operator.mul)
>>> addm(2, 3)
5
>>> addm(4, None)
>>> mulm(6, 7)
42
>>> mulm(None, None)

Or we can lift null-safe versions of other functions:

def string_lens(a, b):
    return len(a) + len(b)

#Interactive python session
>>> string_lens("Hello", "World")
10
>>> string_lens("Hello", None)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "<stdin>", line 2, in string_lens
TypeError: object of type 'NoneType' has no len()

>>> safe = liftm(MaybeMonad(), string_lens)
>>> safe("Hello", "World")
10
>>> safe("Hello", None)

Here string_lens throws when we pass in None, but our safe lifted version takes them in its stride.

Real-world monads

Monads can actually be spotted out in the wild. They particularly enjoy frolicking with pure functional languages, where they can be used for (among other things) getting around the pesky limitation of not allowing side-effects in functions. Mutable state can be simulated by passing a State monad between functions. The I/O monad is used to encapsulate the side-effects of reading and writing from input and output.

Reading through the examples in the Wikipedia entry shows some collections can even be regarded as monads (for example, result can return a list from a single item, bind can map a function to each element in a list). In some instances LINQ statements can also be used as monads. I’ve even seen JQuery accused on monadishness (yes, I just made up a word).

So where’s this leave us? If you’re like me: dazed, confused, craving a cup of tea, and also quite eager to resume working through the excellent Learn you a Haskell tutorial. :)

I’ve started listening to the excellent Ruby Rogues podcast recently, and the recent episode on technical debt really got me thinking about the topic.

The technical debt metaphor

The technical debt metaphor has traditionally been used to explain the impact of using hacky approaches in software development. We can go into debt by trading some quality (be it design purity, code cleanliness, testing, documentation etc.) for a temporary boost in speed.

The metaphor points out that, like financial debt, technical debt also accrues interest. By implementing something in a sub-optimal way we are not simply deferring a fixed time period it would have taken to do the work properly in the first place; that time will increase the longer we leave the hack in and become more dependent on it, or have to work around it in the rest of the code. This means if we accrue too much debt then our project becomes bankrupt – the quality comes so low we can no longer work effectively with the codebase, and the project grinds to a stand still.

The conclusion of the metaphor is that we can take on small amounts of technical debt as required to meet deadlines or other constraints, but we need to keep the debt at a manageable level by regularly paying it back with refactoring and rework to keep the project progressing well longer term.

Inadvertent debt

Martin Fowler points out that technical debt can be accrued both deliberately and inadvertently. Most of the time we just don’t know the right approach in advance, and so end up using sub-optimal solutions that accrue interest and slow us down.

“The moment you realize what the design should have been, you also realize that you have an inadvertent debt… My view is this kind of debt is inevitable and thus should be expected. Even the best teams will have debt to deal with as a project goes on - even more reason not to recklessly overload it with crummy code.”
– Martin Fowler, from his post on The Technical Debt Quadrant

After thinking about this some more I’ve come to the opinion that this doesn’t quite go far enough. We may decide another design may have worked better, but until we’ve done it we don’t really know for sure. The new design will have its own share of problems. It might even be considerably better, but there is more than likely another, even better solution that will become apparent once we learn from the mistakes of the second attempt.

One may even make the outrageous assertion that there is no perfect design for any problem, there are only different sets of trade offs.

Would you like a silver bullet with your free lunch?

Wow, so there is no silver bullet, huh? Bet you’ve never heard that before. ;) While you’re finishing up sniggering something about me and ”Captain Obvious” into your RSS reader, let me try and explain why I find this is a very helpful realisation in the context of technical debt. :)

If we acknowledge there is no perfect design, then every design decision we make is incurring technical debt that we’ll need to pay off. This means that if we try and optimise all our decisions for what appears to be the ideal design, we are quite likely to end up taking longer to strive for perfect when the outcome will be sub-optimal anyway.

That elegant object hierarchy, pattern, or great abstraction added to the application architecture that removes lots of duplication and provides a huge potential for future reuse may seem like the lowest debt solution, but it will not be completely debt free. It will accrue interest and end up costing us as the broad generalisation it encapsulates becomes less applicable as development continues. In my experience the larger the change and investment in that change, the greater the interest rate tends to be.

Rather than looking for the ideal, we may be better off favouring decisions that are quick to implement and reversible/easy to change. Low impact, loosely-coupled changes (i.e. ones that require minimal amounts of changes to existing code) that at first seem less ideal maybe actually give us less debt overall. They may not perfectly abstract away the details of the current problem, but they will be easy to change or remove (along with the debt they contribute) as the needs of the project change or become better understood. Instead of picking the perfect fit for current requirements, we can focus on trying to pick the options that let us iterate and adapt to future requirements.

This kind of thinking can lead us to picking options that at first seem counter-intuitive but end up proving remarkably useful, such as using loosely-grouped classes over strongly-layered architectures, Commands to model database calls via a micro-ORM over persisting large object graphs via full-fledged ORM, using a NoSQL data store rather than an RDBMS, or picking a Front Controller pattern or MVC for a web app over an abstraction like WebForms.

“Right” sometimes isn’t

At least for the developers I talk to, there seems to be a lot of self-imposed pressure for us to pick the “right” design when faced with a design choice; the choice that seems to perfectly abstract the current requirement. The right choice seldom seems the quick, easy option, but is generally one that requires a large amount of work, much of it for the benefit that it looks pure and elegant from an OO and a architectural point of view. I hear (and have made) comments like “That’s a bit ugly. We should extract a common interface, add a factory and (insert lots more work here)”. It’s as if taking the easy option makes us lazy, bad people; that we are somehow failing to live up to the ideals of software craftsmanship.

I think our efforts to do the right thing in these cases can mean we inadvertently do a worse job overall; we are optimising for our current needs but going into debt by borrowing from our future needs. Our decision quickly racks up a huge amount of interest that we have to fight every time we need to make a change that does not quite match the previous requirements. The cost quickly outstrips the smaller, more modular change that would have been long gone, quickly refactored away the moment requirements started to push the code in a new direction. It seems like a good example of perfect being the enemy of the good.

Conclusion

This is not intended as an excuse for hacky code. I am talking about choosing between changes that are made with appropriate tests, taking SOLID principles and good programming practices into account, etc. My point is that the common way of thinking about technical debt can lead us to optimise for the wrong things. Rather than aiming for a beautiful OO abstraction that seems a zero-debt choice, we should acknowledge all our design decisions will incur debt and accrue interest, and so also look for low-impact, reversible changes that will add a smaller debt burden. It’s not a question of whether to take on debt or not; it’s how much to take and where from.

Find

One problem I’ve had is specifying files to pass to git commands when they’re defined somewhere deep within my solution’s folder structure. One option is to use the find command for this:

git gui blame `find . -name MyFile.cs`

This will evaluate find . -name MyFile.cs, which will recursively search from the current path for a file with that name (use -iname for case-insensitive matching). Assuming there is only one match, this works great. If we want to keep operating on that file we can store it in a variable:

f=`find . -name MyFile.cs`
echo $f #check which files we matched. Good idea before destructive cmds ;)
git annotate $f
git gui blame $f

Loops and filtering

If we want to match multiple files, we can iterate over the output of find:

for match in `find . -name *File.cs`; do git gui blame $match; done

# Same thing, but in multiple steps and expanding the loop over multiple lines
# to show what's happening:
$matches=`find . -name *File.cs`
for match in $matches
do 
    git gui blame $match
done

We can also do filtering within this loop. The following example deletes all WIP branches: (use with caution!):

for b in `git branch`; do if [[ $b == WIP* ]]; then git branch -D $b; fi; done

xargs

I always struggle to remember the loop syntax, and it’s not exactly aesthetically pleasing. There is another option: xargs. Xargs is used to build-up lists of argument and execute commands using those arguments. Say we want to delete all our WIP branches again (again: this deletes stuff! Use with caution!):

git branch | grep 'WIP' | xargs -n1 git branch -D

Here we pipe the output of git branch through grep and just pick the branches that contain ‘WIP’. We then pipe this into xargs. The -n1 option tells xargs to execute our git branch -D command once for each argument received (we could pass 3 args into the command using -n3, so the command would execute once for every 3 args). This is a more functional approach, and starts to show the strength of the Unix philosophy of composing many small utilities that all do their jobs well.

I’m only just beginning to get to grips with xargs, but if you read through Things you (probably) didn’t know about xargs and xargs: How to control and use command line arguments you should get more of an idea of what it can do.

Get to know your shell

I recall The Pragmatic Programmer advising to learn a shell really well to help you get more productive. While I’ve only just started looking at this, the more I look the more doors seem to open for automation and getting trivial little operations done more quickly (and importantly, without causing much of a mental context switch from what you are currently working on). Whether you use bash, zsh, PowerShell or even lowly old cmd, I’d really recommend getting better acquainted with what your shell has to offer.

Understanding procedural code

For many of us our first introduction to programming is procedural code. We use variables with different scopes, conditionals and program flow operators like if, while and for, as well as function calls to jump around. This makes it fairly easy and natural for us to trace through program execution by stepping through the code. Now you quickly get to a level of complexity where you can no longer hold the entire program in your head, but there is a certain sense of reassurance that we could start from the beginning of the code, and step our way through to the end to understand the code.

By comparison OO can seem like you’re drowning in a sea of indirection. You no longer just step through the functions being called, but you also need to understand the state of the objects those functions live in, what types are in use due to polymorphism, or even which method will be called once virtual method dispatch is taken into account. For example, you may try and trace the execution of an IFoo.DoSomething() call, only to find you have no idea which implementation of IFoo is being used. Maybe it’s a CompositeFoo which aggregates a WidgetFoo and a GadgetFoo, and GadgetFoo may have an instance of an IAmAtABar, which will completely change what it’s DoSomething() method does. Surely this OO is a horrible beast to be avoided at all costs! (Cue functional programmers nodding in agreement ;))

Hiding details is the point of abstraction

This is not a problem with OO. This is the very point of OO. OO allows us to abstract away details so we only deal with a cohesive, understandable amount of information relevant to the abstraction level at which we’re working. It’s ok not to understand the whole thing at once. I’m pretty sure you’re not meant to.

Rather than tracing through a procedural program from top to bottom, for OO programs we move sideways along a plane of abstraction to find the collaborators at that level. Our ProcessOrderCommand calls BillCustomerCommand and ShipInventoryCommand. I don’t know that BillCustomerCommand checks the customer is in our loyalty program and this order qualifies for a 10% discount. That’s a different level of detail that lives at another level of abstraction. All these little details are mercifully hidden so we can understand that processing an order means billing a customer and shipping some inventory to them.

Holding all the combinations of state at each level of abstraction in our heads becomes a near impossibility, but we don’t need it. That’s what our abstraction is for; encapsulating all the details and freeing us to work at the optimum level of abstraction for our current problem. We can then switch between levels of abstraction to get the information relevant to the problem we’re trying to solve.

How can obscuring details be a good thing?

We pay a price for the traceability of procedural code. It tends to be hard to change because the code is all about implementation; the “how” rather than the “what” or “why”. This can also make it hard to test, because isolating a section of code from the execution state is difficult, which makes it even harder to change with confidence.

OO trades of some of this traceability for the ability to use abstractions in the form of objects in our code. By hiding details at one level we can better see the main features of another; we can see the forest for the trees. Abstractions also let us express the “what” and “why” of the code. Because we’re programming to abstractions we can potentially change the details those abstractions encapsulate without affecting the rest of the system. In fact we can modify the behaviour of our system just by adding objects, rather than modifying existing code (see Open Closed Principle of SOLID). This encapsulation of details also lets us isolate small units for testing purposes.

Abstraction can be painful

Now it’s important to realise there are costs to the OO approach. We’ve talked about losing some of the ease with which we could trace through procedural code. This can also make concurrency difficult when we need to synchronise bits of state in different places. There can also be problems with the impedance mismatch between abstract concepts and technical implementation. A related problem is that of leaky abstractions, where the encapsulation we’ve chosen breaks down in places and affects other parts of this system, increasing coupling and actually making the code harder to change (the opposite effect of what OO is designed for).

While we can mitigate against these problems, it’s worth acknowledging that we will experience some level of pain from all these issues when using OO. OO gives us a lot, but there’s no such thing as a free lunch. This is, incidentally, a great reason to look at other programming paradigms, as well as different frameworks and languages that all address these issues in different ways and to differing extents. Combining techniques (such as functional and object-oriented) can help give you some of the best of all worlds.

Getting the most from abstractions

There is a whole lot of design guidance that can help us with OO abstractions. SOLID, the 4 rules of simple design, TDD and related disciplines, GRASP, etc. I really recommend looking into all that stuff, but for this post I want to look at it from the more general viewpoint of what we want to get out of the abstractions (read: rant).

• Don’t mix levels of abstraction. Each piece of an abstraction should be at a similar level of detail.
• Abstractions are lots of work. Don’t have one if you’re not willing to look after it. You will need to nurture it and help it grow into a useful member of your design society. Corollary: don’t use too many abstractions. They should be small and cohesive. The aim is to do more with less code.
• Define abstractions around things that need to change together. If you need to add lots of views to your app, writing a new view should not require changing bits of 7 different abstractions. Similarly, if you are only going to be using SQL Server, you don’t need to abstract that fact away so you can plug in a new DB engine (although your data access details will probably live at a similar level of abstraction, so it won’t be impossible to change either). Optimise for the things that change all the time. One big class that never needs to change is preferable to 30 tiny classes that all need to change all the time.
• Favour wide abstractions over deep ones. In other words, favour aggregating/composing several collaborators, rather than having many layers of objects (A uses B uses C uses … Z). Having to traverse many layers of abstraction down a deep hierarchy to pass one new piece of data is soul crushing.
• Keep data close to where it is used. Having to pass the same piece of data through many abstractions is also soul crushing.
• Don’t hide the important stuff. You want to abstract away the unnecessary details, not the key feature of what you’re working on.
• Obey the Law of Demeter. She will try and tell you when your abstractions are leaking. You can then fix these leaks by applying the Tell, Don’t Ask principle.
• Tests can be another good guide to tell you when your abstractions are going wrong. If you need to do loads of setup or reach into lots of different collaborators then your abstraction is wrong. Unfortunately it doesn’t tell you how to do it right, but if you write the test you wish you had first, then you have a better chance of getting the abstraction you need.
• Avoid creating abstractions for testability alone. A well abstracted design should be naturally testable, but not all testable designs are well abstracted. The Reused Abstractions Principle (RAP) tells us to look for valuable abstractions. Just testing against an interface does not mean we have a good abstraction. (Thanks to Xerx for pointing this out.)
• Modelling the real world as objects is probably not what you’re after. Read Uncle Bob’s Coffee Maker example (linked to here). (Aside: this doesn’t conflict with the goals of DDD, which works to accurately reflecting business needs and concepts.)
• Layered / n-tier architectures do not necessarily help with abstractions. If you need to force your classes into presentation, business logic and data access layers, then your abstractions are not free to grow or (more importantly) shrink as required. Maybe the abstractions you choose will naturally group together into layers, or maybe each abstraction will have its own layers. I think forcing it can be detrimental though. If you want to change how you are loading data for a screen (say, optimised query instead of what your ORM generates), you don’t want to fight the weight of every other data access abstraction in the code.
• Separate infrastructure code concerns from app-specific abstractions. Abstractions should be modular), the infrastructure can compose them together. An example of this infrastructure is your friendly neighbourhood IoC container. (We also want to keep infrastructure small and prevent it bleeding into our abstractions; again, less is more.)
• Ideally you want to be able to be able to try out new abstractions without fighting against the existing ones and without breaking too many conventions. Admittedly I have not found a good solution for this, but keep it in mind when designing and consider how much work it would be to do this differently if required for another feature.

Finally, remember there is no single right abstraction for a given problem. This still seems more art than science, and practice and experience will trump all the rules and guidelines you can find. The trick is finding ways of experimenting productively with different options in both real and hobby projects.

Abstraction

Back in the old days I spent more time than I care to admit writing procedural code in classes. More recently I’ve also played around with Over-enthusiastic OO (OOO), using insanely fine-grained objects for everything. These approaches roughly correspond to not enough and too much abstraction.

And so begins my hunt for the right amount of abstraction. I find fine-grained objects with single responsibilities really nice to work with at a micro level, but at a macro level the weight of useless abstractions can be crushing.

This weight is a symptom of violating the Reused Abstractions Principle (RAP), which Mark explains very nicely. (I’ve also experienced this as the NAF problem, or “Not Another Factory”. Anyone else felt this?) The trick is finding the “right” abstraction that captures a reusable aspect of the system. This is made harder in C# by the fact(?) that it makes effective unit testing difficult without creating abstractions everywhere.

So my options include hoping to drive out the right abstractions and assume that this will magically make it easy to test without using otherwise useless abstractions, or starting to use more real stuff in unit tests (having larger units, with potentially more suitable abstractions), in which case my tests get messier as I throw loads of data through my tests to exercise all the code paths.

One thing I’ll definitely rule out is going back to procedural code where classes are little more than a namespace, as I found this quickly became unmanageable; difficult to change, impossible to test effectively, and a nightmare to build on. At least my poorly chosen, testable abstractions are better than untestable spaghetti.

Refactoring

Another thing I’m struggling with is refactoring. I find the distinction between refactoring and redesign helps, but it’s not always quite that simple. Sometimes despite refactoring the little section of the code you’re currently working in and around, the tendrils of previous design decisions still reach out across many other classes. Once you have coupling like this, when can you ever clean it up by refactoring alone?

Contrived example: if you have ye olde layered architecture and are passing data (or transformations of the same data) through the layers and through multiple classes, untangling all the places this data has spread can only really be tackled in a redesign. And, as described in my original post, once you are in the territory of redesign you are optimising for today’s cases and possibly making your next change harder if it tries to flex in a different direction. On the other hand, the overall design is getting increasingly bloated and harder to understand as you continue to build on it while making localised design changes using refactoring.

Is it possible to gradually refactor even these wide-spread problems? Or are there times when you just have to bite the bullet and redesign? Is it just a case of writing off the redesign time that could otherwise be spent on features your customers care about, in the hope it will speed you up later? Or is it a case of admitting defeat; the design can actually become too compromised to completely fix if we miss too many cues to refactor, and we just have to go into legacy code mode and keep making local improvements in the hope that these isolated changes will eventually link up and restore a fairly clean, usable design?

End rant

So those are the problems that are currently weighing on my mind.

On one hand, I can see an incredible amount of value in using very fine abstractions, but on the other abstractions can quickly turn into a dead weight that impedes progress. I’m torn between continuing to get the benefit of lots of small classes, and trying to reduce the amount of weight and noise contributed by the less-useful of my abstractions.

On the refactoring side, I’ve advocated small, localised refactoring in the hope of gradually pushing a design into good shape, but I’ve also observed times when this just doesn’t seem possible. In these cases the only options seem redesigning larger areas of code, or just capitulating to entropy and keeping small islands of cleanliness within the mess (this is in keeping with Eric Evans’ somewhat depressing observation that “the natural state of all software is a big ball of mud”). The problem here is trying to decide what approach to take, and balancing time invested now versus the future cost of not making that investment. I’m also bothered by the idea that the only evidence we have to base this decision on is poorly-informed guesswork and gambling based on that.

Experience over multiple projects would most definitely help this, but as the real pain of this stuff seems to be felt in large-ish, multi-year projects, this experience and chances to experiment with different approaches is hard to come by.

As a quick aside, I’m pretty sure these two problems I’m having are closely related.

Appreciate any thoughts or counselling on offer. :)

public interface IProperty<T> {
    T Value { get; set; }
    event Action ValueChanged;
}

The traditional way of doing this in .NET is to subscribe to events:

    [Test]
    public void WithEvents() {
        _property.ValueChanged += OnValueChanged;

        _property.Value = 5;
        _property.Value = 10;
        _property.Value = 15;
        _property.Value = 2;

        _property.ValueChanged -= OnValueChanged;
        Assert.That(_propertyValues.ToArray(), Is.EqualTo(new[] { 10, 15 }));
    }

    private void OnValueChanged() {
        var value = _property.Value;
        if (value >= 10) {
            _propertyValues.Add(value);
        }
    }

Here we subscribe to the ValueChanged event. Every time the event fires our OnValueChanged() method will be called, which will check if the property value meets our condition, and if so then add it to _propertyValues (a list of int).

The other alternative is to change from looking at this situation as the procedure of responding to each event by looking up the Value, to looking at the changes as a collection of Values produced by the events. This is where Rx comes in. (At least this is my newbie interpretation; please correct me in the comments.)

Everything I know about Rx in under 200 words

Rx seems to revolve around 2 main interfaces (that I believe shipped with .NET4, and are also available from Rx for .NET 3.5). The first is IObserver<T>, which has OnNext<T>(T item), OnError(Exception error) and OnCompleted(). This interface is the dual of the iterator interface (IEnumerator<T>), which just means that rather than iterating over a collection, we get each member of the collection pushed to us.

The other interface is IObservable<T>, which just has a Subscribe<T>(IObserver<T> observer) method that returns an IDisposable. This lets us register an observer to start receiving pushed items, and dispose of the observable to clean up subscriptions.

Rx itself is a whole heap of supporting implementations and extension methods to help us do incredibly cool things with those two interfaces*. Rather than looking at these incredibly cool things, let’s look at our previous example instead, partly because the cool things are covered in many places, and partly because this example is adapted from a real problem I had to solve, so I know it’s something we might be able to use in day-to-day development. :)

Observing the values of our changing property

I initially stuffed up my effort to get this working using Rx by creating a terribly naive implementation, but thanks to a very helpful StackOverflow answer from Scott Weinstein it’s now looking pretty neat.

The first thing we need to do is create an IObservable<T> over our property value. Rx has built-in methods to do this from events, but only when they follow the standard event handler signature (whereas ours is declared as event Action). Instead we can use Observable.Create<T>() to help us. (We could do this in-line where we want to use it, but I’ve wrapped it in an reusable method because I’ve got lots of properties where this will come in handy.)

    public static class ObservableEx {
        public static IObservable<T> FromEvent<T>(Func<T> selector, Action<Action> subscribe, Action<Action> unsubscribe) {
            return Observable.Create<T>(obs => {
                Action pushNext = () => obs.OnNext(selector());
                subscribe(pushNext);
                return () => unsubscribe(pushNext);
            });
        }
    }

This looks a little more confusing than it actually is. Observable.Create<T>() takes a delegate which itself takes an IObserver<T> and returns an action that disposes of our observable. In the body of that delegate we put the logic necessary to push values to the observer. This is the subscription logic for any observer that subscribes to our observable.

In this case we push whatever value is returned by our selector, and subscribe to the required event so we push whenever that event is raised. When our observable is disposed we unsubscribe. And here’s how we use it:

    [Test]
    public void WithObservable() {
        ObservableEx.FromEvent(
                () => _property.Value, 
                action => _property.ValueChanged += action, 
                action => _property.ValueChanged -= action)
            .Where(x => x >= 10)
            .Subscribe(_propertyValues.Add);

        _property.Value = 5;
        _property.Value = 10;
        _property.Value = 15;
        _property.Value = 2;

        Assert.That(_propertyValues.ToArray(), Is.EqualTo(new[] { 10, 15 }));
    }

This is the same test as before but rewritten to use observables. We create our observable over our property value based on its ValueChanged events using our extension method. We then filter this collection of values using a standard, LINQy Where clause. Finally we put our logic for handling occurrences of this particular observation by calling Subscribe and giving it a callback to execute; in this case our logic to add the value to _propertyValues.

Compared with the previous approach, we have consolidated event subscriptions, unsubscriptions, filtering the values and the logic of handling the values we’re interested in to a single observable declaration. Having all this related information together is great, but being able to declare our intention in the code rather than the procedure we need to implement it is, IMO, awesome. Not to mention how nice it is to have our event subscription cleaned up for us when our observable goes out of scope. :)

This may seem like a silly example, so let’s look at a more realistic case where the same code could come in handy. Say we want to run some diagnostics whenever a device gets connected. We could observe the device’s connection state, filter it to just look at Connected values, then run the required diagnostics code when we get this value. Better yet, we can also combine observables, so we could subscribe to notifications only when the device is connected, its driver has reported it is ready to use, and the software is running in diagnostics mode. This would make for messy event handling code, but be quite readable as code combining and filtering observables.

I’m definitely keen to play around with this more, and hope I’ve managed to get those of you that have been putting it off (like me) interested enough in it to do the same. :)

But I don’t use mocks! I use stubs!

Let’s start by clarifying that by “mocking” I’m referring to the mocks and stubs we use as test doubles; the kind we tend to get from our mocking/substitution/fake/isolation framework of choice. By “types we don’t own” we’re talking about any type that isn’t defined and tested as part of the current build (or solution, to use Visual Studio parlance). This includes anything from types in a base class library to APIs for accessing another system or service.

When mocking makes sense

To me the sweet spot for mocking is when we’re using TDD to drive out the design of a collaborator that doesn’t exist yet, or one that requires modification.

In these cases we’re defining how the type will act, and we have the ability to adjust this behaviour as required by the type’s consumers by altering these tests. At this level our design is really quite fluid; we can shuffle responsibilities between types, and create new or collapse existing types as we see fit. We are working within our own abstractions, optimised (hopefully) for making our code easy to work with.

A more general form of this case is when we want to isolate a class under test from its dependencies. This allows us to configure explicit behaviour for our test doubles so we don’t need to test a whole host of input combinations; we can assume the collaborators’ behaviours and just worry about the class under test. It also can shield us from long running tests by replacing slow collaborators (such as those that make database or web service calls), or from difficult test setups due to collaborators that need to run in an explicitly configured environment (such as those that make database or web service calls), or from unreliable tests due to collaborators with variable behaviour (such as those that make database or web service calls ;)).

However this more general case has landed me in trouble more than a few times when I’ve tried mocking (and stubbing) the interactions with types I don’t own.

Tests that do little

When we are writing a test as part of TDD we are primarily specifying how our type will behave, and as a result defining the behaviour of the type’s collaborators. The interactions between these types are tested as well, but the next step we’ll do is drive down into the collaborating type and make sure it will work as required. As we have full control over the types at each end of the exchange, we can be reasonably confident our real code is going to do what we expect. After all, we wrote and tested that code in accordance with how our tests told us it was going to behave.

For types we don’t own we don’t have this level of transparency. They already have a fixed design and behaviour specified elsewhere. By testing interactions with a mocked version of this type, we really are not using our test to check for the correct behaviour, nor to drive out a collaborator’s design. All our test is doing is reiterating our guess as to how the other type works. Sure, it’s better than no test, but not necessarily by much. Just because we have checked we successfully called database.Save(data) doesn’t mean that we didn’t need to call database.OpenConnection() first.

Even when we know an external library really well, and so completely understand the interactions required, mocking that library can still give us misleading tests. If we update the library version and there has been a subtle change to the required interactions, our tests can still pass but our code will fail. Just because we have always received events in a particular order from a library doesn’t mean we can assume that will always be the case, particularly if it is not documented behaviour and/or it was just a side-effect of the implementation used in previous versions.

These integration issues can also be a problem with types we do own, but I’ve found that because we’re driving out each step in an end-to-end behaviour, we get added transparency and more focussed abstractions that tend to make this much less common than when dealing with external types.

Tests that do too much

Another risk we run in specifying all the required interactions with types we don’t own is having overspecified tests. These tests quickly become a pain point; they are hard to change because they are so coupled to the specific implementation and pattern of interactions with a type, and refactoring which doesn’t actually change the behaviour can result in tests failing.

This can also mean large, convoluted setups as we attempt to mimic the way the collaborating types work, which can make our tests difficult to read, understand and maintain. In general, once we find ourselves setting up complex interactions and behaviour using mocking framework constructs, chances are we’re doing it wrong.

This can be mitigated to some extent by the way we encapsulate the library and the setup needed for our test fixtures, but eventually we’re going to have to pay for the impedance mismatch between our abstractions and the abstractions used for the type we don’t own. Which segues neatly to our next point…

Corrupted abstractions

Depending on the complexity of the interactions with types we don’t own, the abstractions used for those types can leak into and influence our own abstractions. We may add abstractions just to give us enough visibility into interactions with these types to ensure we have specified all the calls we expect, rather than because they make sense to the problem we are trying to solve. This could mean a whole lot of wrappers over external types, or new factories to create specific objects required by the interactions.

This isn’t necessarily bad, but it does mean we’re no longer writing the code that best solves or abstracts away our current problem, and also can leave us more tightly coupled than we’d like to the library that owns the type. Because we’re not defining the behaviour in our tests, we end up coupling our design to the implementation of the external types instead.

Writing and maintaining these additional abstractions can also be quite expensive, especially considering the questions we’ve already raised about how useful those tests are.

Remember, external libraries are built to help people solve a general problem. When we design code for a project we are trying to solve specific problems. An abstraction that is handy for addressing the more general problem is not necessarily going to match the abstractions that help us.

Well how do I test code that uses external types then?

One way of looking at this is that we are switching from TDD-style tests with the aim of driving design to good old fashion “check this works” tests. In my experience the mindset is fairly different, as are the tests themselves.

One way of making this switch is to use the real types and do an integration test. Test drive our design down to a level of abstraction that is useful, then integration test over the boundary. Rather than checking our class interacts with an external type in a certain way, we check it gives us the behaviour we require.

If we are testing that we’re using an ORM properly, we can use the real ORM and database and check that we can load up the required details after a save operation. If we’re using Castle DynamicProxy, then we can call our code that uses DynamicProxy and check the object we get back forwards to the interceptor we expect, rather than asserting we return a specific object from a mocked ProxyGenerator class we don’t own and whose ins and outs we may not fully understand. We’re checking the consequence of the action, rather than the details of the action itself.

This isn’t to say that we add a whole host of tests around a component we don’t own – we really need to have a little faith in it working as advertised otherwise it would probably be quicker to just write our own. Instead the purpose of our test should focus on getting some degree of confidence that our use of the library has the basic desired behaviour. Rather than stating we need certain interactions with the library, we can use some simple, focussed cases with the real types to sanity check assumptions we made about the required interactions.

I’ve found that doing this frequently gives me much cleaner tests and implementations than if I had wrapped and tested the different elements of the interactions with types from another library. Provided the abstraction I’ve ended up with in my own code is OK, testing the behaviour tends not be too arduous.

As an alternative (or ideally complimentary) approach, we can use acceptance tests to make sure the entire feature works as expected (i.e. not just covering the call over the integration boundary, but exercising as much of the real feature as possible). Again, we’re checking behaviour, not implementation specifics for types where we don’t have a constant, transparent view into those implementations.

What about when I just can’t use the real type?

There are times when using the real types is not practical. Maybe setting up an email server on each dev machine and checking the email account receives the required email is too much for our regular test suite (possibly a great test to run on a CI server or similar though). Or perhaps actually firing the doomsday device just isn’t prudent for a test case that runs several times an hour… :)

In these cases we can create our own fake version of the external system or library. This is probably not going to come from our mocking framework of choice; as previously mentioned, once we find ourselves setting up complex interactions and behaviour using mocking framework constructs, we’re probably doing it wrong. The important thing is to verify that our calls to the fake are compatible with the real classes, and where possible check that the behaviour matches what we expect. Martin Fowler calls these Integration Contract Tests. The idea is that if we pass a certain range of values to our fake, the real version should also be able to handle these values. If we assume the real version behaves in a certain way and replicate that in our fake, we can write a test to try and verify that assumption.

In some cases we can use the real type with a different configuration as our fake. For example, we could run tests through our ORM configured to use an in-memory database. This won’t test the final hop to our target RDBMS, but it will give us some confidence that our use of the API is correct, and we can setup more comprehensive tests against the real configuration on our CI server.

Limitations of integration tests

It would be remiss of me not to mention J.B. Rainsberger’s assertion that integration tests are a scam, which is nicely summarised by Gabino Roche Jr. I’m not proficient enough with this stuff to talk definitively on this, but I’ll give you my 2 cents, then you should go through J.B.’s work and see how you can apply it. It’s also worth looking at the GOOS book; it has some really interesting examples of how to effectively use acceptance tests for driving development, including the need to deal with other libraries and systems.

My limited understanding of J.B.’s objections to integration tests is that they are not going to ensure correctness (you can’t test exhaustively), they can be brittle and difficult to write and maintain, and that they can end up as a “self-replicating virus” when used as a crutch any time a programmer can’t find a good, testable abstraction and therefore can’t unit test the code.

Almost without fail whenever I have mocked a type I don’t own I end up experiencing pain. Best case is I get lots of fairly useless abstractions that cover different operations within the external library’s API. Worst case is I get lots of useless abstractions that don’t work with the real API and are really difficult to change. This only leaves me with integration/acceptance-style tests for code that uses these types, so for me the question becomes one of how to write these tests effectively while trying to limit the legitimate problems J.B. has highlighted. I don’t have the answer to this, but here’s some guidelines I’ve been using:

• If possible, limit the amount of exposure we have to the external library. When using DynamicProxy for NSubstitute we could get away with using only a very small part of the library, which meant we had only a few things to integration test.
• The abstractions we choose are important; they can determine how much work we have to do in each interaction with the external system. If there is a big mismatch between the abstraction we’ve driven out and the external code we need to work with, it might just be a sign we need a better fit for our requirements. (e.g. maybe we should persist using a document DB instead of an RDBMS? Or maybe just throwing data on the file system would fit better?)
• Accept we can’t test exhaustively, and focus on the most helpful cases. We generally want to assume the external stuff works as advertised, so we really just want to get some confidence that we are using it in a way that seems to give us the behaviour we expect.
• If we keep coming up against integration bugs, adding integration tests is probably not the answer. We may need to examine ways we can push out more responsibility into unit-testable abstractions to simplify the integration.
• Sometimes it is worth the time to develop a good, fake implementation of a complex external system. Examples include simulating external hardware, or using an in-memory database instead of an external one.
• Make the tests easy to read and write. If you have long, complicated test setups we need to either look for better abstractions, or encapsulate the setup process in its own abstraction.

Conclusion

In summary, my current thinking on the subject is that while using mocks and stubs is really beneficial when driving out the design of collaborators using TDD, it is important to identify when we need to stop test-driving and start testing. This is generally the point where we hit a type we don’t own from a library or external system.

Using test doubles for types we don’t own can end up with fragile tests that don’t actually test much of value, or can even compromise our design and the effectiveness of the abstractions we use. Even when mocking a library we know really well we can end up with compromised abstractions and fragile tests due to relying on implementation details or assumptions based on previous versions of the library.

I’ve found switching to integration and acceptance tests to test over the boundary between my code and the other types a very useful alternative, but it is important to be aware that this approach can bring its own problems, and we need to try and mitigate these when writing our tests.

And finally, we should remember that this is just a guideline. If we find a situation where it is going to be both safe and simpler to mock a type we don’t own, we may as well do so, but at least we’ve considered our options. :)

Have I got this all wrong? Please leave a comment or email me at davesquared.net. :)

For this post we’re going to take a look at why I feel TDD is so hard to learn, at least to the point where it can be used effectively for everyday coding tasks. From there we’ll look at how and why TDD works, with the goal of giving new TDD practitioners a way to critically evaluate the introductory material they come across, and hopefully avoid some of the mistaken assumptions that can slow down the learning process. Finally we’ll look at some ways this understanding can help people with some of the questions that commonly crop up starting TDD.

Why is this so hard?

I think there’s a few reasons learning TDD is so difficult. Firstly, I think the hype around TDD can be quite detrimental to the learning process. Depending on which sources you read it is easy to get the impression that TDD is the only valid way of writing software, and that by following the simple steps your code will turn out gleaming with cleanliness, filled with only obvious, beautiful abstractions. In my experience, for all but the simplest of examples, this is just not true.

The unrealistic expectations set by the hype can cause people to become overly focused on the process, without understanding the rationale behind it. This can result in developers applying TDD in an ineffective manner. It can also become very frustrating for the leaner, as they see the process that worked so well for implementing a Stack leave them lost and feeling inept when trying to use it to put something simple on a web page.

TDD is not a substitute for thinking. It is not a replacement for design skills. It is not actually driving anything – the developer is, and so TDD will only go as well as its driver. A more realistic view of TDD is that it is simply a tool that can be used to help you get a job done. Sure, it can be a remarkably useful and powerful tool, but in the end the goal is to get the job done*, not to start every bit of code with a failing test.

The other reason I believe TDD is hard to learn is that the TDD process itself actually gives you very little guidance as to how to practice it. When trying to learn something new a common first step is to learn a set of rules and go around applying them fairly mindlessly until enough experience is gained to know when to bend or break them. Eventually you start to see the rationale and patterns behind the rules and realise that how to apply them depends mainly on the context. Hence the infamous standard answer from experts: “it depends”.

Now with TDD the rules are trivially simple. In fact they are so simple they don’t give you enough guidance to mindlessly apply them until you gain enough proficiency to start achieving success with TDD. Instead you also need to know how to appropriately abstract your design, which requires in-depth knowledge of OO design, patterns, SOLID, DRY, etc. This can make TDD very hard to use effectively until some of these gaps are filled. Now TDD is an excellent way of highlighting deficiencies in these areas, but it isn’t quite so forthcoming with the answers.

Understand the mechanism, then learn to apply it

I think one way to make TDD easier to learn is to make a concerted effort early on to understand how it works. Sure, start with the trivial, one class kind of example to learn the basics of the red-green-refactor process, like implementing a Stack [PDF link] or StringCalculator, but then stop and think about what the process is doing.

We start by writing a failing test. Why? Our current tests are all passing, which gives us feedback that there are no known problems with it. By writing a test to expose a deficiency we are clarifying the problem we are trying to solve. Constraining the problem and therefore the possible solutions in this way makes it easier to solve (a divide and conquer-style approach). We’re also making sure this code will be tested for both correctness and protection against regressions, but that’s not exclusive to TDD; you can get that writing any decent automated tests.

Most importantly we’re also sketching out a design, but rather than doing it on a whiteboard (which has its own advantages) we’re doing it in code and getting immediate feedback as to how usable it is and how easy it is to test. Let’s think about the kind of questions we need to think about in order to write this failing test:

• What is our System Under Test’s (SUT) responsibility? i.e. What should it do, and when should it do it?
• What is a convenient API for making the SUT do this?
• What does the SUT need to discharge its responsibility? (Data? Collaborators?)
• What output or side-effects are there to observe?
• How can we tell it worked correctly? How is “correct” defined?

These are all questions that should be asked at some point when writing any code. The power of TDD is that it provides us with a convenient tool for thinking about these questions. Rather than having to go through each question in turn, resolving potentially conflicting answers as we go, TDD lets us address the more abstract question of “How can I write the next test?”, and in the process infer a solution that also addresses the more concrete questions. This is why TDD is no better than its driver; you still need the skills and experience to answer the same questions. TDD merely gives you a tool to make it easier to think about them.

How exactly does this more abstract question help us? Like all useful abstractions, it gives us a way of thinking of a lot of details as a single whole. We can now tackle all those little details in a single train of thought, in a form that lets us apply both our technical skills and our creativity to finding a solution. And while tackling that single question we get the benefit of another of TDD’s strengths: rapid, accurate feedback.

The process of writing the test gives us all sorts of feedback. The setup is too long or complicated? We’ve probably got too many collaborators (or are violating the Law of Demeter for them) and can try encapsulating them behind a new abstraction. Too many scenarios or test fixtures on the same SUT? Our SUT probably has too many responsibilities. Too hard to isolate the behaviour we’re trying to test, or can’t find how to write an assert for the behaviour? Maybe the current API or abstraction is wrong, and needs to be broken down differently? With TDD these problems become obvious very quickly. Solving them requires design skills, but so does any other approach to development. Writing the test first gives us ample opportunity to respond to this feedback, to sketch out our design, before committing to it. There is no cheaper time to change your code than before it is written.

Next we make our test pass with the simplest code we can justify. Funnily enough this is the least interesting part of the TDD process. We’ve done all the hard work in specifying our behaviour, now we just take the relatively simple step of making it work. Is it too hard to get working? Then we drop back to change our test; TDD has just given us feedback that our test is forcing too big a leap. Is the implementation so trivial it has obvious flaws? TDD has just given us feedback to tell us what our next test should expose.

Finally, we have the refactoring step. Our code works, but we’ve been focussed on passing a very specific test which only shows a very small picture of the application. Now is our chance to zoom out and take in the entire application. If we’ve used a naive implementation to get our tests passing we can clean up this duplication, or extract methods to help our code be more self-describing. Even more important is noticing larger scale duplication; finding not only repeated code, but repeated activities that can be abstracted or made a transparent infrastructure concern.

How does this help?

Glad you asked! Provided you accept my rambling above, we now understand that TDD helps constrain the scope of the problem we’re looking at, gives us a relatively simple way of thinking about the large number of design questions that apply to that problem, and provides rapid feedback on how well we are addressing these problems. This knowledge can help get us through some of the problems that can trip up people learning TDD.

What test should I write?

Well the flippant (albeit accurate) answer is whatever test provides you with the feedback you need to further your design. This answer is hardly going to help people just starting out unless we delve into a bit more detail.

What I struggled with most while learning TDD was moving from the simple, unit test driven examples to using TDD for real code. If I picked a unit test of a class lower down the hierarchy I’d have problems fitting the driven code back into the design. The problem was I wasn’t thinking about how I could use my tests to give me feedback on what to do. If I had started with a test that described what I was trying to do then I would have been able to start driving out abstractions that actually helped me solve the problem, instead of blindly abstracting myself in circles. The trick is to pick a test that encapsulates what you know about the current problem.

Let’s look at a more extreme case to illustrate this. Say we have a brand new project. In this case we’re not even sure what classes we need. How can we use TDD to get feedback on our class design when we don’t even have a class? Well, let’s write a test that describes the feature (or story) we’re working on. This will be an acceptance test rather than a unit test. No one said TDD has to exclusively use unit tests, but as most examples for new practitioners concentrate on the process they all seem to use unit tests, hence the common misconception. This process will allow us to sketch out a basic architectural skeleton which we can flesh out and modify as we go along. Our test will provide us with feedback on how well we’ve managed to break the feature’s requirements into manageable, testable abstractions. We’ll also get a nice programmable interface to our system for future acceptance and integration tests. I found the Growing OO Software Guided By Tests books a great source of examples of how to do this.

Once we have defined the basic behaviour for the feature via the acceptance test we can implement some of the infrastructure required for the test (build, CI etc.), and then pick the top class our test has discovered and start using more granular tests to drive out our classes. Or perhaps we won’t even need more granular tests; the direction given by our acceptances tests might be sufficient for us to implement the feature.

But you just wrote code before writing a test!

Sure! TDD gives you feedback on design. When you already know what’s required (say you’re filling in pieces to comply with a set architecture) the design part of TDD is not giving you much benefit. The only real positive of writing a test first in this case is that you ensure the test fails first; it’s a way of testing the test. This is test-first development, not TDD.

The less unknowns we have, the less our tests need to teach us, and the larger steps we can take.

You picked an MVVM pattern and defined a view without a test!

We’ve already learnt that TDD constrains the problem space we are looking at, as well as provides feedback on how well we are addressing this problem. Of course TDD isn’t the only thing imposing constraints on us, nor our only source of feedback. Our choice of UI technology (WPF, an MVC framework, GTK, WebForms etc) imposes very real constraints on how we deal with our UI.

One way to address these constraints is to use a separated presentation pattern such as MVVM. In that case, we might define the properties and commands we need on a ViewModel without a single test. We’re constrained by our UI technology, the UI pattern we’ve chosen, and the screen design we’ve worked out during discussions (another medium with rapid feedback) with our customers.

TDD isn’t our only source of constraints and feedback. Where real constraints exist we don’t need to force new ones by using TDD and ignoring reality.

I’m stuck! I’ve test-driven myself into a hole and can’t get out

I’ve done this an embarrassing number of times. I’ve used tests to guide every line of code, including lines I write as part of refactoring, and ended up stuck in a maze of pointless abstraction. Remember, TDD is not a substitute for thinking, you still need to be able to code.

If TDD is not giving you the information you need, back up and try something else. Go through some ideas with colleagues as a white board. Use test coverage at a higher level of abstraction for feedback and work from there. Maybe spike some solutions (it is often faster to try out 3 different solutions than try and figure the best solution up front). TDD is one way of getting good constraints and feedback, but it is not the only way. Do what works for your situation, but make sure you think about it later and try and find the reason you got stuck.

TDD? BDD? ATDD? Which should I use?

You might notice that the use of TDD is very problem-specific (and developer-specific for that matter). Different problems raise different design issues that will require different types of feedback. This means we’re going to have to apply TDD in different ways to give us the feedback we need to drive out our application’s design. This can be top-down or bottom-up. In some cases we could lean very heavily on acceptance tests. Other times we might like to drive out implementation by a whole lot of unit tests. Still other problems may be well-served by end-to-end tests that actually hit an external database or service (these have their own issues, but if they are helping you get the feedback and design you need, then go for it!).

There isn’t one right answer; you need to focus on getting the feedback that helps you get the job done.

Conclusion

While the rules for the TDD process are simple, learning to use it effectively is anything but. The rules themselves give us only minimal assistance when we’re starting out, and the hype surrounding TDD can give us unrealistic expectations about what it will do for us.

We can address this by trying to understand how TDD works; the rationale behind the rules. We’ve seen that TDD is really just a way of constraining a problem, encapsulating the process of design by using the abstraction of a test, and providing rapid feedback as to how well our design is going. The process essentially gives us a nice way to think about and iteratively do design.

Once we understand this we can start trying to apply TDD in a more targeted manner, deliberately applying it in ways to give us the feedback we need to make design decisions. We won’t restrict ourselves to unit tests alone, but will switch between testing at different levels of abstraction without feeling guilt over not using an unit test as all the introductory examples seem to. Nor will we feel guilty when we make a decision without TDD’s feedback, instead relying on other feedback like other systems we’re interacting with, the UI technology we’re using, or the persistence technology that’s been mandated company-wide.

We’re also not going to feel inept when we fail to apply the deceptively simple TDD rules, as we realise TDD is just a tool to help us think about design problems, and that there are always going to be gaps in our knowledge and experience we need to fill before we can solve new problems. The fact TDD has illustrated these gaps quickly gives us an opportunity to learn right away, rather than leaving us in blissful ignorance until things explode as a deadline looms, or worse, keeping us unaware of and repeating the same mistakes time after time.

Design is hard. TDD gives us one great way of thinking about it and learning how to do it better.

If you’re currently learning TDD I hope these ramblings have given you a different way of thinking about it that will help make your journey a little easier. Best of luck – I think you’ll find TDD well worth the effort! :)

In case this post wasn’t long enough for you…

This post summarises what I’ve learned to date from my TDD journey. Have a look at the following posts if you’d to read how my thoughts on this have evolved over the years (they’re listed from oldest to latest). They’ll also provide some more details and/or examples of some of the ideas discussed in this post.

• Scenario-based testing
• Example of driving design through top-down testing
• Calculators and a tale of two TDD styles Part 1, Part 2, Part 3
• Favour test driving logic over data
• What exactly is TDD driving?
• Improving TDD skills via treatment of test infection
• Don’t test drive while refactoring
• TDD vs UTDD

Anyway, I’ve tended to struggle with this when using Rhino Mocks, and end up randomly trying various forms of repeats, such as Repeat.AtLeastOnce() or Repeat.Any(), before I get it to work.

I recently found a better way thanks to a thread on StackOverflow: just use a closure.

public interface IDoStuffWithInts { int GetAnInt(); }

[Test]
public void Change_return_value() {
    int valueToReturn = 0;
    var stub = MockRepository.GenerateStub<IDoStuffWithInts>();
    stub.Stub(x => x.GetAnInt())
        .Return(0)
        .WhenCalled(x => x.ReturnValue = valueToReturn);

    valueToReturn = 7;
    Assert.AreEqual(stub.GetAnInt(), valueToReturn);
    valueToReturn = 11;
    Assert.AreEqual(stub.GetAnInt(), valueToReturn);
}

Unfortunately you need to set a dummy return value first, but you can then override that using WhenCalled. This makes it easy to change the stubbed value by changing the variable. I’ve found it useful to sometimes wrap this in a helper method, such as MakeStuffDoerReturn(int value).

Hardly ground-breaking I know, but hopefully it will save someone else a bit of pain. :)

I love rules. I’m a rules addict. I find them strangely liberating; they restrict my options so that I can better focus on the creative aspect of whatever I’m doing. They seem to promise repeatability, predictability, and a degree of mechanical perfection that just needs to be nudged together by the developer.

Luckily for me there’s no shortage of rules. There’s SOLID, the 4 rules of simple design, DRY, Tell Don’t Ask and a whole bunch of step-by-step patterns and refactorings to mindlessly apply. ;)

Of course, it’s never quite that simple. Rules should come with a disclaimer, WARNING: Some assembly required.

No matter how many books I read, how many blogs I subscribe to, or how many patterns I memorised, a nice design never really seemed to naturally emerge from all that knowledge. So I tried quizzing experts on the rules they use. And pretty much without fail the answer was “it depends”. You give them a specific case, they give you an answer. You ask for a rule, and they tend to reply with words like “generally” and “favour”, not a specific procedure.

At a course a few years back I even quizzed the instructor until I managed to distil the procedure for getting beautiful designs from BDD. The instructor himself couldn’t explain the procedure, as he said much of the decisions are based on context developed from experience. Of course, that didn’t stop me trying to get to the rules at the heart of it. Nor did those rules assure my success at producing good designs.

Rules are the question, not the answer

Much as I generally dislike some of the grandiose metaphors that are typically attributed to software development by software developers, one that sticks out as quite relevant here is the Japanese martial art concept of Shu Ha Ri, which describes the three stages of learning required to master a discipline. (At least as I understand it. Please correct any egregious errors I make :))

The first stage, Shu, is all about rules. The beginner memorises the rules and applies them dogmatically. They may not see opportunities, or be able to take advantage of them, because they are sticking to the rigid forms they are learning.

The second stage, Ha, is when the beginner gains enough experience and has internalised the rules enough to start pondering the reasons behind the rules. They slowly begin straying from the rules as they start to notice the shortcomings when applying them to the myriad of situations the world throws at them. They also start to gain a better sense of appraising the relative success or failure of these experiments, and so start to apply rules on a case-by-case basis.

The final stage, Ri, is when the practitioner has risen above the rules. Every situation is dealt with on its merits. An observer may notice many elements of the rules in action, but the practitioner is merely doing what is required of the situation as governed by their experience; the context they have built up by applying and deviating from the rules.

While all this may seem a little twee, I can’t count the large number of times I have talked to people that really seem to know their stuff, and found they seem to have this uncanny knack of seeing straight to the heart of a problem and solving it in an elegant, seemingly effortless way. I can see many of the rules present in their approach, yet their solution never seems to be one I could simply derive by applying the rules or a specific formula. In hindsight, the solution tends to seem obvious; but never before I’ve seen it.

This has led me to believe that rules are the question, not the answer. They are what starts us on a path of enlightenment. It is only once we have memorised the rules and start noticing their limitations that we start asking ourselves why the rules are there and how they work. Once we start this questioning, we start gaining some mastery of the discipline. And it is only after we no longer need the rules that we are truly proficient, and we have uncovered the answer of how to write good software.

And, as many consultants will tell you, that answer is “it depends”. ;)

So now what?

Well, I’m trying to break my rules addiction. I like to think I’ve spent way too much time in the Shu phase due to it’s inherent safety (rather than as the result of fundamental incompetence), and that it’s time to start looking past the safe-haven of those rules. More than anything I think this comes down to writing loads of code, trying out new approaches, taking risks and questioning the meanings and motivations behind the rules.

How much time do you spend looking for rules on how to develop software right? If the answer is “lots”, maybe it’s time to let go of them?

Remember quicksort? Picking a pivot, then putting it in the middle of the sorted smaller elements and sorted larger elements? Typically you end up with a wad of procedural code, such as this fairly typical C# example.

In Haskell, you work more with describing what something is, rather than how it works. So we end up with something like this:

quicksort :: (Ord a) => [a] -> [a]
quicksort [] = []
quicksort (x:xs) = smaller_sorted ++ [x] ++ larger_sorted
    where smaller_sorted = quicksort [y | y <- xs, y <= x]
          larger_sorted = quicksort [y | y <- xs, y > x]

The first line is defining the type of the function, it takes a list of orderable types and returns a list of those types. The second line is our recursion edge case: sorting an empty list returns an empty list.

The third line is the definition of our algorithm. Given (x:xs), the list head (x) and tail (xs), we put the head between the sorted list of everything smaller and the sorted list of everything larger.

The where clause has our recursive calls using list comprehensions. The line [y | y <- xs, y<=x] selects the elements of the tail (xs) which are less that our pivot (x).

Neat huh?

We can also try and bring the functional-style with us to C#, but you pretty quickly start missing pattern matching, and built-in list syntax like head, tail and concatenation. In many cases (like this one) the C# compiler also won’t be able to get you the tail call elimination possible in functional languages like Haskell, which tends to make recursive implementations less desirable.

public static IEnumerable<int> QuickSort(IEnumerable<int> elements) {
    if (!elements.Any()) return new int[0];

    var head = elements.First();
    var tail = elements.Skip(1);

    var sortedSmaller = tail.Where(x => x <= head);
    var sortedLarger = tail.Where(x => x > head);

    return QuickSort(sortedSmaller).Concat(new [] {head}).Concat(QuickSort(sortedLarger)); 
}

This is simpler than the more procedural version, but not as simple as the Haskell version. And we still have to stay concious of differences such as how tail recursion is handled over different platforms which can have a huge impact on performance. With that in mind though, it’s neat enough for me to keep digging into functional programming, as even if I don’t end up doing much with pure functional languages the techniques can provide some very interesting alternative ways of solving problems in any language.

I will not knowingly contribute, or condone the contribution of, bad code to a project.

Let me tell you a story.

A tale of two projects

Before I start, let me assure you that we are talking about internal code quality here. DRY, SOLID code. The scenarios discussed below are all uncompromising about product quality. The final products go through strict verification protocols to ensure quality. This is obviously completely independent of the internal code design, which is more to do with how easy the code is to change in light of new requirements etc.

So, towards the end of 2010 my team had several quick projects to get through. All had unachievable deadlines, all had a small scope and small domain, and all were of relatively low importance (more research experiments than shippable products).

For the first of these we had 6 weeks. We used an Agile project approach with one week iterations, did TDD, wrote acceptance tests, etc. Clean code all the way. The software that shipped at the end of the third iteration was good enough to fulfil all the major requirements and everyone was really pleased. We added some extra polish and features in the remaining weeks.

The last of these went quite differently. We were given three days. We estimated we’d need three weeks. We communicated that the deadline could not possibly be met, but resolved to do everything we could to get it working as quickly as possible.

After a bit of debate, we decided to ditch any attempt at clean code and just do whatever it took to ship it as quickly as possible. It was a small project with next to no maintenance requirements, so we figured write-only code would be ok. No SOLID, DRY code meant no slaving over the IDE extracting interfaces, or driving out a nice design using rapid feedback from TDD. We wouldn’t use acceptance tests, but would manually test as required, and only automate any testing that was easy. We had a continuous build, but skipped the full deployment build to ship at the end of an iteration; probably because we didn’t have iterations. The scope was small, so we decided to use only very broad, coarse-grained stories and just work until they were done. We still had our rigorous verification protocol to pass, but it was a small project, how hard could it be?

As I said, we were meant to have it done in 3 days. We figured it would take three weeks. It should have taken three weeks.

It ended up taking three months.

The way to go fast is to go well

Our decision to abandon any pretence of working towards clean code was our undoing. Not making much of an effort at design or removal of duplication resulted in tight coupling and obfuscated code. It was effectively a write-only code base; the simplest of changes became all but impossible, including fixing what should be simple bugs or catering for clarifications to requirements. It was very difficult to find seams for testing bits in isolation, and changes would frequently ripple through the code. Our lack of rigour around project planning and story breakdown made it impossible to track our progress. Time saved by not automating repetitive tasks was re-spent ten-fold on mindless, error-prone tasks when we should have been writing code to finish the project.

Let me make this very clear: anyone that tells you working toward clean code is a waste of time and will slow you down is completely wrong.

You cannot trade internal quality for speed. I give you about 30 minutes of coding before you need to change something where an automated test would have made you faster. As you can read from the earlier post, I was pretty convinced of this already, but experiencing such a dramatic illustration by far surpassed my expectations in terms of the return on investment in clean code. Previously I would have guessed we’d start feeling pain after about a week of hacking, but it started almost immediately. I am now adamant it is impossible to have anything but an illusion of productivity without writing clean code.

As Uncle Bob puts it, the way to go fast is to go well.

Clean code is a journey, not a destination

None of the above means gold plating your code. Your code need not be a shining beacon of architectural and OO greatness, gazed upon with awe by artisans for centuries to come. Your code is never completely clean; clean code is not an end state, it is about the process of reducing coupling, reducing duplication, simplifying, and clarifying intention whenever you work with your code.

This does not mean you must practice TDD. It does not mean you need to use a particular language or framework. It does not mandate a project methodology. It doesn’t mean you can’t spike. It doesn’t mean you can’t knowingly take on manageable technical debt. It doesn’t even mean you must unit test. It means that you need to do what it takes to ensure your code is maintainable. That your code has the qualities we associate with clean code: it works, it is maintainable, it is correct. It is not about trading quality for speed, because that is an illusion. It is about doing what it takes to produce what’s required as quickly as possible, and that means you can’t afford to write cruddy code.

In short, don’t ship $#*!.

Conclusion

And so back to my resolution, which was always a high-priority goal of mine but never an unwavering commitment, never before a line I simply will not cross. I will never deliberately contribute or support the contribution of bad code to a project. I will always strive to write clean code, not in pursuit of some programming utopia, but in the sincere belief that it is the only way to quickly and effectively deliver a project.

I wish you all the best of health, happiness, and clean code for 2011. :)

Quick recap

The problem is fully described in the original post, but it basically starts with this class:

class Greeter
    def say_hello
        puts "Hello World!"
    end
end
greeter = Greeter.new
greeter.say_hello
#=> Hello World!

I then wanted to replace say_hello on that single greeter instance with a method that would close over a local variable, like this:

name = "Anonymous Dave"
# replace say_hello on greeter so it puts "G'day #{name}"

greeter.say_hello
#=> G'day Anonymous Dave

name = "Clarence"
greeter.say_hello
#=> G'day Clarence

Standard reopening of the instance (or even the Greeter class) and redefining the method won’t work here, all because we have the pesky requirement of closing over our local name variable, which means we need to use a block (basically a lambda function for C# people). We can use Class.send to call the private define_method which takes a block, but that will add it to every instance of Greeter, not a single instance.

Modules to the rescue

We solved this in the original post by referencing the instance’s metaclass (aka eigenclass), but there is another way:

name = "Anonymous Dave"
new_say_hello = Module.new do
    self.send(:define_method, :say_hello) do
       puts "G'day #{name}"
    end
end

Here we’ve created a new anonymous module that sends define_method to create a say_hello method using a block, in the same way as we could have reopened the Greeter class and added it to every instance. The difference here is that this module has not been mixed in anywhere yet; we can choose exactly where we want to apply it. In this case, to our single instance:

# Mixin module to greeter instance to add our new say_hello method
greeter.extend new_say_hello

greeter.say_hello
#=> G'day Anonymous Dave

name = "Clarence"
greeter.say_hello
#=> G'day Clarence

# Other instances are unaffected by this:
another_greeter = Greeter.new
another_greeter.say_hello
#=> Hello World!

I think I still prefer the Meta module approach, but this way has the advantage of sticking closely to standard Ruby constructs and manages to avoid metaclasses.

What was most helpful to me out of this as a Ruby n00bie is the understanding that we can work using class scope within a module (avoiding metaclass shenanigans), then apply that scope selectively by including the module in a class, or by extending an instance with the module.