Ayende @ Rahien

Refunds available at head office

A New Methodology: Blog Driven Development 2.0

I would like to introduce a new Methodology for development. I call it Blog Driven Development and it is a modified version of XP.

Here is the entire Methodology in its simplest form:


What projects this Methodology is fit for?

Just about any project you like, but I strongly recommend that you will use BDD for Web 2.0 projects, since it mesh well with empowering the developers and result in better product that can be readily consumed by millions of eager users.

As you can see, I'm practicing my own craft and use BDD daily for the last two years or so. I've been very successful so far.

Please note that this Methodology means that you Blog a Lot, Test a Little and Code a Little. The implicit assumption here is that you slowly shift the effort from coding and testing toward blogging. As blogging is a field that is far more deterministic than software development, I am sure you can imagine the productivity increases.

You can set clear goals and schedule with confidence. Imagine how much better your standing will improve when you repeatedly meet deadlines.

Other benefits of Blog Driven Development:

  • Sending a blogger to a journalist's conference cost much less than sending a developer conference.
  • You are on top of the hype wave, using BDD to develop Web 2.0 projects is the Big Next Thing, I assure you.
  • You can reasonably expect to catch most "bugs" using Word's spelling & grammar checking.
  • Less code means less bugs


I am currently taking a sabbatical in order to write the Tome Of Blog Driven Development, you can read a sample chapter here.


Published at

Castle And Bicycle Riding

A while ago I was trying to explain the benefits of Castle to developers, and I just couldn't get through. It is pretty easy to explain the benefits of using Active Record, but I had a hard time explaining MonoRail and Inversion Of Control.

Here is my elevator speach for MonoRail:

MonoRail is RAD MVC framework built on ASP.Net that supports the Front Controller pattern and force strict seperation between UI and Business Logic.

I got into a lot of problems with this, since it doesn't convey the benefits to the people I am talking to. The response that I got where:

  • RAD without wizards? There is no such thing.
  • MVC? Front Controller?
  • I already has seperation between the UI (aspx) and the Business Logic (aspx.cs)

I can show how quickly I can create a page, but it will seem slow compared to doing the same thing in VS.Net, since I don't have a designer to "help" me. How do you explain the benefits of design patterns to those who doesn't feel the pain*? How can I explain the benefit of strict seperation to those who think that aspx / aspx.cs is good enough seperation?

I got the same problem when explaining Inversion Of Control, they couldn't get why they shouldn't just use new. Do you think that those things, like bicycle riding, can only be understood by actually trying them?

I know the motivation parts of those patterns, but I don't think that I managed to make the people I was talking to get the advantages of this new way of doing stuff.

* Those Who Doesn't Feel The Pain - I like this pharse.

Test Driven Development Is About Failing

This post has nothing to do with Rocky's comments on DNR

I was testing using NHibernate in ways that I never did before*, and the test kept failing. Each time I would fix one thing, and another part would break. It wasn't very obvious how to make it work. I had a guy watch over my shoulder while I worked throught the kinks of the problem. After the test failed repeatedly for the 10th time or so he just muttered something about "never making it work right" and walked away to do something else.

To me, TDD is all about failures. I know that I need to do something only when I get a failing test. And the failing test kept pointing me to this error and that error, and I kept researching and fxing the errors. Eventually I had enough understanding of what I was trying to do and how NHibernate was trying to accomplish it that I could get it to work (perfectly). All in all, it took about 30-40 minutes of trying.

I am not upset to see failing tests, they are the best sign that I have that something is wrong.

This is a Failing Test.
There are many other tests, but this one is a Failing Test.
My Failing Test directs me where I need to be going.

* Highly complex schema with some indirection thrown in to add to the mix.

Wish: Reflector.Debugging

One thing I really wish that I could do is to make the debugger use Reflector if it can't find the source files for an assembly. This would be a nice way to track problems into the framework (or other libraries). This is what I have to do today, but I do it in my head, which doesn't really work.

Avoid Mixing O/RM and SQL

It is common to people that are starting use O/RM to get into a situation that they don't know how to solve using the O/RM (or even aware that such a thing is possible). The easiest example is loading just Id and Description for a certain class without loading all the (possibility expensive) properties.

There are several ways to do this using most O/RMs, but they are usually not obvious to the beginner. This is usualy a pain point since they can easily see how they would do it using plain SQL, but they either don't know how to use the tool appropriately, or they just don't think this is possible using the O/RM. The immediate solution to that is to just use plain SQL (or SP) to solve this one problem.

It is wrong because it pokes big holes in the model you show the rest of the system. If means that the model that most of the system is using doesn't match the model that the rest of the system is using.

This is bad because you lose of of the key benefits of using O/RM, abstracting the database. A good O/RM will always let you work against the objects structure, not the data structure. This is important because it frees you from dealing with a potentially ugly schmea and work with a good model all the time.

In nearly all the cases, you can use the options that the O/RM gives you, and get what you need without dropping to SQL. That is not to say that SQL isn't important. It is very important, because O/RM tend to be leaky abstractions, it is just that you shouldn't reach to the familiar tool when you need to solve a problem without an immediate solution.

What I'm more afraid of is that using SQL to solve the immediate problem will start to spread through the code, since "it is already the way we did it in XYZ". And that is a whole new can of worms. Letting this spread means that you effectively have two data access layers for a single application for the same model. I trust that I don't need to explain why this is bad. Just the syncornization between the two will be a pain, and considerring the way the SQL Access Layer is likely to appear (growing from quick solutions to problems), I am willing to be that it is not going to exhibit good design (at all levels).

If you really need to use both, make sure that you investigate the options to solve the problem using the O/RM first, and then make sure that this solution goes through the front door with all the bells (Design, Tests, Code).

Rocky Lhotka on TDD, Take #2

Rocky took the time to clarify his comments on TDD in dotNetRocks #169. There seems to be a couple of main points there:

As a testing methodology TDD (as I understand it) is totally inadequate... ...the idea that you’d have developers write your QA unit tests is unrealistic

TDD is not a QA methodology. TDD is about designing the system so it is easy to test. This makes you think about what the code does, rather how it does it. The end result is usually interfaces that are easier for the client to work with, coherent naming for classes/interfaces/methods, the level of coupling goes down and the cohesion of the system goes up. Then you run the test.

The idea in TDD is not to catch bugs (although it certainly helps to reduce them). The idea is to make sure that developer think about the way they structure their code before they start writing it. It also means that developers has far more confidence to make changes, since they have a test harness to catch them if they break something.

And it was pointed out on Palermo ’s blog that TDD isn’t about writing comprehensive tests anyway, but rather is about writing a single test for the method – which is exceedingly limited from a testing perspective.

You start with a single test, to check the simple case, then you write another test, for a more complex case, etc. The purpose is to assert what you are going to do, do it, and then verify that it does what you assrted it should. QA isn't going away in TDD, for the reasons that Rocky mention in his post (developers rarely try to break their app the way a Tester does). QA and Developers takes two different approaches. When I get a bug from QA, I write a failing test for this bug, and then I fix it. Now I got a regression test for this bug.

When I touch this part in 6 months time, I can do it with confidence. I know that I will not:

  • Break any of the assumtions of the original developer - I got tests that verify that the original functionality works
  • Regress any bugs that were found before - I got tests that would verify the bug is fixed.
  • Any future maintainer of the code will not break the sutff I'm doing now - I write tests that will verify that the new functionality is working.

Those and clear design are the main benefits fo TDD, in my opinion. Again, I agree that this doesn't remove the need to have QA team that hates the product and really want to break it :-).

I don't buy into TDD as a “design methodology" either. You can't "design" a system when you are focused at the method level. There’s that whole forest-and-trees thing... ...But frankly I don’t care a whole lot, because I use a modified CRC (class, responsibility and collaboration) approach.

CRC is cool, I agree, but the issue is how detailed you go. I can probably think of the major classes that I need for a project up front, and maybe even come up with their responsabilities and some of the collaborators. Until I sit down with the code, I can't really say what methods and what parameters will be at each class, what other stuff I need to do this work, etc. TDD is about the interface/class/method design, not directly about full system design (although it will influence the system design for sure).

And as long as we all realize that these are developer tests, and that some real quality assurance tests are also required (and which should be written by test-minded people) then that is good.
None of which [developer tests and QA tests], of course, is part of the design process, because that’s done using a modified CRC approach.

This is something I really do not agree with. If you don't use TDD to influence your design, you are not doing TDD, period. You may have tests, but it's not TDD. Writing tests after the fact means that you don't get to think about what the client of the code will see, or use things that make it much harder to test the class. You lose much of the qualities of TDD.

What you end up with is a bunch of one-off tests (even if they are NUnit tests, mind) that doesn't cover the whole system, and are only good for testing very spesific things. They don't affect the design of the code, which can lead to very cumbersome interfaces, and they don't cover the simple to complex scenarios. They may represent several hours (or days!) of programming effort that culimate in a long test that test very spesific scenario. Those are integration tests, and while they have their place, they are not Unit Tests. NUnit != Unit Tests.

And here is a reply to some of the comments in the post:

Sahil Malik commented:

TDD does_not reduce your debugging time to zero. You do end up with an army of tests to maintain. Since the tests are written by and maintained developers, you cannot go with the assumption that the tests themselves aren't bug free. So you write tests to check your tests? Inifinite loop.

You do not stop debugging, that is correct. It does mean that you have a very clean arrow that points to where it failed, including the details, so you have much easier time to fix it. And having an army of tests to maintain would be bad if they didn't have an army of code that they test. Yes, tests has bugs, and the code has bugs, but the chance that you would get the exact same bug in both the test and the code is not very high. When you will see the test fail, you'll investigate and discover that the code is correct and the bug is in the test. No need to write TestTheTestThatTestTheTest... scenario.

Code Annotations

I want something like this thing:



It got to be as easy to use and it should be integrated into VS.Net, so when I open a file, I can see the annotations for the code. I know I saw something like this, but it was using pen (and presumably tablet), and I can't find it right now.

Published at


Do you ever print any of your code? I can't recall the last time I did it, and I know that it was never something that I did often. I'm not a real example, since I print about 2 pages a month on average (and even that I'm doing while muttering bitterly about dinosaurs).


I can see one good use for printouts, and that is for paper code review. I can see the value there, especially since red pen is one of the easiest ways to communicate. Although, I guess I would get stuff like this one all too often:

The only things that I print right now are object / tables diagrams, and even then, I don't refer to them, I'm using them as darts targets. (You wouldn't believe the amount of holes the Page class had during the time I did ASP.Net work).

Outlook Spam

I just noticed that emails that goes to the Junk E-Mail in Outlook are displayed as plain text, and that the links there are not working. That is, they are clickable, but they won't take affect (it was annoying to find this tidbit, because it looked like it should work).

Obfuscation Question

The question is actually very short: Why?

I just saw an obfuscation package for .Net that goes for over 600$, and I'm not sure if that is per developer or not. I know that there is this belief that obfuscation will protect your IP, etc, but I fail to see the point in this endavor.

I can see several scenarios for wanting to obfuscate the code:

  • You are a component vendor and you don't want people ripping you work and using it elsewhere.
  • You ship a product out and fear that people will decompile your code, remove the registration routine and re-compile it.
  • Your code contains classified information or secret business logic.
  • You think that it is your code, and I have no business looking in there.

For the component developer:

What is valuable is not how you do that trick with triple buffering or custom event handling, or the Ajax capabilities, or whatever. What is important is that the whole component mesh well with the rest of the envionment and that it is easy to work with. If I got a problem in your component I will go into Reflector and try to find what is wrong. I will be seriously pissed off if I can't figure out that I should've prefixed a \ because the code is obfuscated. If someone is going to rip you off, obfuscation isn't going to help, if they need to take the whole thing as a black box, they will. And then were you are?

I'm going to use maybe 10% of the capabilities of what you give me, if I'm going to have to fight it, I'll rather just roll my own, it's simpler to do so and at least I can control what is going on.

For the obfuscation will make it harder to crack my product:

No, it won't. I can run your product under the profiler, find the path of calls that blocked me, and just return "true" from the IsLicensed() method. It's a lot of work, and in general, I have better things to do with my time than break products when I can just pay for them. That said, there is a certain class of people that enjoy this challange, and yet another section of humanity that uses their labor to use your labor without paying.

Obfuscation only make the game more interesting, and considerring that obfuscation doesn't change the meaning of the code, it all turns into a mental challange similar to this. At worst, they will just check the x86 assembly that is being JITed and see what you are doing in that level.

For the classified information / secret stuff in my code:

What are you doing giving away your confidential data to the users anyway? If it is really secret, then you should put it somewhere you control, and only let people access it if they are authorized. Putting the classified information in the client just means that A) they can access it if they need it and B) they likely to do so without you knowing so. If it is secret, you should keep it under lock. The moment it is in the hands of the users, it is only secret as long as no one tries to find it. If it is not really secret, than it's either #1 or #4.

For the guys that thinks that I shouldn't look at their code:

You code is not likely to be anything speical, sorry. I regulary goes over libraries I use with Reflector, it's a mini code review that I do, mostly to familiarize myself with the library and the options that I can use. Several times I rejected libraries because the way the structured their code, under the assumstion that if they did such a bad job in this, it's not going to be easy / fun to work with the API that exists, and the general quality of the code isn't going to be stellar (to say the least).

Paul Graham On Software Patents

Paul Graham has a great article (as usual) about parents, which contains the following quote, that got a bona fide Laugh Out Load from me:

...when you're saying something that Richard Stallman and Bill Gates would both agree with, you must be perilously close to tautologies.

This is nice as well:

Instead of the canonical "could you build this?" maybe the corp dev guys should be asking "will you build this?" or even "why haven't you already built this?"

The nicest part is at the very bottom, but it has a comment that has all the sentiments of a slashdot reader:

If they [big business] agreed among themselves never to do business with any firm employing anyone who had worked for a patent troll, either as an employee or as outside counsel, they could probably starve the trolls of the lawyers they need.

I must say that I agree with this sentiment, although I don't see how enforcable this is.

Testing UI - A Challange

Here is the story:

When the a node in the graph is hovered via the mouse, a connection point (a node can have several) is made visible, and the user can drag the connection point to another node (when it enter the second node, the second's connection points will be visible) and create a connection between the two connection points. A visible line should exist when dragging the connection, and after it was attached it should be permenantly visible.

I got this to work without tests, since I just can't think of how to test this stuff. Right now I'm heavily using the functionality that Netron provides (which does 96% of the above) and the implementation uses windows events and state tracking quite heavily to get this functionality.

I suppose I can try to refactor the logic out so it would be testable, but that would mean duplicating the events structure for WinForms. In addition, I can see no way to test that the correct stuff is drawn to the screen and I am not fond of taking a screen shot and then comparing the known good to the result on a bit by bit basis. If for no other reason than that I can think of several dozens of tests for the functionality that I need.

Any suggestions on how to test this?

Nice Interview Questions

Mike has got several interview questions that I like. They are not tied to spesific technology but they manage to check a wide range of topics. They are pretty basic, though, so I would use those to screen people for a much harder interview.

Published at

Testing UI, Again

I’m testing UI again, and I guess that it is going to suck this time as it did before. This time I’m using Netron for the graphs, and it’s not that bad this time, mainly because I can get into the guts of Netron and change it, and this make all the difference in the world.

The problem with that is that while Netron is a library for graphs, it is mainly for painting graphs, so it got a boat load of baggage that I don’t need when I’m doing testing. I started using the Pass Null pattern, but there seems to be lot of stuff that just can’t accept null (and doesn’t check for it).

I didn’t look too deeply into the way Netron is structure, I admit, mainly because there is quite a bit of GDI stuff that I just don’t want to get into, but I guess that I’ll have to, at least to rip out the parts that I’m not using and don’t want to maintain. The main problem I’ve with Netron is that it needs to keep a lot of state, which makes life hard when you try to understand what is going on around you. The framework is there to help you build really complex stuff, but I managed to scale it down without much trouble.

I just realize that I can just use the whole thing for testing without bother the UI bits. This mean deleting my façade code (always a pleasure) and using the real thing, and it doesn’t affect the way I’m working with the model.

All things aside, Netron looks really good, check out the sample applications screenshots. I managed to get a working sample that looked about as good as Microsoft’ Class Designer in no time, and Netron takes care of most of the details with regard to object movement, highlighting, connecting the dots, etc.


Published at

More on the .Net Framework

Can someone justify when I get those types in the System namespace? (from the System assembly)


  • NewsStyleUriParser  
  • GopherStyleUriParser
  • Etc..



I mean, I get that networking is important but isn’t putting NNTP and Gopher(??) in the System namespace too much?

Published at

More Rants about .Net Design

There are way too many places in the class library that are internal without cause. The entire ASP.Net caching system is one big internal block, and the Compression namespace has only two public members.

I need to read just the header of a zip file, as far as I can see, this is certainly possible using the classes in the framework, but they are all marked internal, so I have no way in short of using Reflection.

I get the issues with the testing matrix, and the possible backward compatibility issues that may happen when developers use stuff that you may want to use. But the documentation contains quite a bit of classes where the only documentation is “This class is for the framework internal use only” which should be warning enough for developers that they may change without warning.

Published at

Ranting About Design: System.IO.Compression.GZipStream vs. ICSharpCode.SharpZipLib.GZip.GZip*Stream

I had a change today to look at the implementation of both classes, and I really don’t get what went through the minds of the developers in Microsoft when they wrote this class.

To be (brutally) short, GZip is a derivative of the Deflate algorithm with some additional headers tucks on it. This seems like an ideal case for inheritance, put the Deflate algorithm in its own class, and then put the GZip handling in a derived class.

On the surface, this is what both Microsoft and #ZipLib did, but I took a look inside today with Reflector and found that System.IO.Compression.GZipStream is nothing but an empty shell around DeflateStream. I mostly expected that, but I was very surprised to see that no where in GZipStream there was handling of the  GZip headers.

Looking a little deeper, I found this constructor:

internal DeflateStream(Stream stream, CompressionMode mode, bool leaveOpen, bool usingGZip)


It makes the OO developer in me cringe in pain. Why would they do that? This means that the DeflateStream needs to knows about its children, that it has specialized behavior for one specific child, etc. This is just wrong.

The #ZipLib got classes that actually have behavior, by the way. That is, the child class extend the functionality of the base class. This sounds familiar, I wonder where I heard those before…

Published at

NHibernשte Generics Release 1.0.4, Bug Fix

Looks like I made an error in EntityList, and ended up calling the wrong delegate on RemoteAt().

This is fixed now, and you can get the updated binary and sources here.

Thanks for Matej for finding out the bug and directing me to the exact line in the code where it happened.

The return of PVOID

I think that the Daily WTF should be required reading for developers. I don't believe that I would have ever thought about using the language like that. Check out the Vector Oriented Programming, or the really dynamic typing, sure to bring tears to the eyes of old timers around the world. It combine hard coded indexes, random data types and the familiar sense that you need to remember the manual by heart (and memorize a passage each day, lest you start to forget) before you can do hello world in the system.

In summary: WTF!?!

Null Method Invocation

About 6 months ago I left a comment here, and I returned now to check it, and found a real gem. Check this out, it is about invoking methods on null, like this:

Foo foo = null;

 Wesner Moise explains what the possibilities are:

... An instance method can treat an null in special, default way to maintain continuity with nonnull objects and eliminate the need for callers to perform null checks. One example of this is how it simplifies the manipulation of binary trees. It's similar to the null object pattern, with the null object being null.

I can certainly think of several ways that this would be nice to use. It was removed from C# by the ECMA during the standardization process. It may be a good thing, I don't know if stuff like this are good (because they open up possibilities) or bad, because they mean more stuff to care about. Anyway, I'm not sure that I would ever want to see something like "if (this == null)" in my code any time soon.

One thing to note, this is supported by the CLR. C# will emit a callvirt IL call, which will cause a null reference exception, but this IL works just fine with no exceptions ( showing just the call, see the C# source below):

.method public hidebysig static void             Main        (string[] args) cil managed
      .maxstack 1
      .locals init ( TestNullMethodInvocation/Inner inner1, bool flag1)
      L_0000: nop     
      L_0001: ldnull
      L_0002: stloc.0
      L_0003: ldloc.0
      L_0004: call instance bool TestNullMethodInvocation/Inner::InstanceMethod()
      L_0009: stloc.1
      L_000a: ldloc.1
      L_000b: call void [mscorlib]System.Console::WriteLine(bool)
      L_0010: nop
      L_0011: ret

This translate to this C# call (except for the call vs. callvirt, of cours):

using System;
public class TestNullMethodInvocation
 public static void Main(string[] args)
  Inner inner = null;
  bool result = inner.InstanceMethod();
 public class Inner
  public bool InstanceMethod()
   return true;


Published at

Underused NHibernate Feature: Creating Objects In The Select Clause

I got a comment today from Jim Bolla asking about this query:

select new Address(c.Address, c.City, C.Zip) from Customer c

His comment was:

I've been using NHibernate for at least 6 months now and haven't heard of this feature. Does this really work? What are the requirements/limitations? Is this in the documentation? Or even in the example code/tests?

As he didn't leave an email or another way to contant him, I'm going to broadcast the reply to the world, hoping it would get back to him. (As an aside, if you ask a question, I need a way to get back to you, so leave a way to do so).

First, it is a documented feature that you're welcome to use. It's not used much (and sadly I couldn't find a test for it after a quick grepping), mainly because it is obscure. I just gave it a quick test, and it is working correctly. One word of caution. you need ot make sure that you imported the type that you are trying to create. Here is the sample test:


public class QueryThatCreatesAnObject



    public void CheckCreatingObjectsInSelectClause()


        ISessionFactory factory = DatabaseTests.CreateSessionFactory();

        ISession session = factory.OpenSession();


        session.Delete("from Blog");



        Blog blog = new Blog("ayende @ blog");




        IList list = session.Find(@"select

                    new System.Collections.DictionaryEntry(b.BlogID, b.BlogName)

                    from Blog b");

        Assert.AreEqual(1, list.Count);


        DictionaryEntry de = (DictionaryEntry)list[0];

        Assert.AreEqual(de.Key, blog.BlogID);

        Assert.AreEqual(de.Value, blog.BlogName);



As you can see, it's pretty slick. I'm not 100% about how you import a class, and I don't have the time to investigate, but the documentation for that is here.

Testing the unknown

I set out today to write something that I never did before, but which I thought was too small to deserve a true spike. I'm talking about my persistance to code implementation, of course.
I started by writing the following test:

public void SaveEmptyGrap()
    Graph g = new Graph();
    StringWriter sw = new StringWriter();
    string actual = sw.ToString();

I had no idea what I was going to get, but I went ahead and played with the code until it compiled, and then I looked at the result, verified that it was correct* and used that as the expected value.
I could then move on to the next test, graph with nodes, using the same method.

* Just to note, it turned out that I missed putting the method name in Code Dom, which meant that my expected string were wrong. I found out about that only when I tried to load the graphs again. It wasn't hard to fix, but I wanted to point out that this method has its weak points.

Testing as a motivation

There has been a lot said about testing and their affect on the code. I just had the tests affect me as I write the code. You are probably aware that I started a new project recently, and I've (as always) taken my time with a lot of spiking on the design.
Even when I am spiking, I feel very nervous without the tests, and because I'm making such profound changes to the application, there are long stretches of times when I can't even get the application to compile.
This mean that thinking about something and seeing it fail (and it always fails the first time) takes very long time. It also means that I waste quite a bit of time in going the wrong direction.

Today was the day when I finally settled on the design that I would have, and started sweeping thorugh the code, looking for stuff that needs to be tested. I think about this an un-legacifying the code that I wrote this past week (which had only two tests, one of them 40 lines long, yuck!).
I added a lot more tests, renamed a couple of methods, applied the Law of Demeter and voila, I got a code base that is a pleasure to work with.
Then I could start writing features using TDD, and get the rapid feedback that I crave. I actually added value today, which is a great feeling to have in the end of the day.

Saving graphs as Code Dom, part 2

I posted a few days ago about Saving object graphs to file: CodeGen and Executable GraphsI just wrote the final test that made it all happen! I got objects that knows how to persist their state to code, and then load themselves right back from this code.
This is the first time I worked in Code Dom, and it was very easy to get it to work very quickly.

This is a huge security hole, of course, but I'll probably just play with the AppDomain permissions so the only thing it will be able to do is to give me the complete object graph. I got to say, there is quite a bit of satisfaction in saving files in this format. Very readable.


Published at