Speaking in general terminology “Late Bound” can mean a lot of things. Late bound resolution can mean resolving which method is invoked as part of a VTable lookup. Take for example the definition of “Dynamic Binding”

http://en.wikipedia.org/wiki/Dynamic_binding_(computer_science)

Follow this link on similar spirit.

http://martinfowler.com/bliki/ComposedRegex.html

Not quite – there’s a huge difference between a virtual method call and a late-bound method call.

The white space is non issue, just use underscores. It’s close enough to a space that your eyes will read it as one. I’m not sure why some people perceive underscores as evil in test names.

My favorite feature is the elegant assertions. It almost reads like English.

Square 5 |> should equal 25

Is better than

Assert.AreEqual(25, Class.Square(5));

I’m sure you can come up with some extension methods for the object class that make a fluent-like syntax, but this just can’t be beat.

I do wish to point out something to you though. Your statement, “Case studies have been conducted, the experts have weighed in, and the results are unequivocal” is far far from true. This is evinced by your opening statement: “The Agile practice of Pair Programming is one of the more controversial development techniques within the software development community.” The reason it’s so controversial is because it IS so hard to unequivocally prove it’s superiority.

Just because Kent Beck says something is so doesn’t make it true. It’s the natural complexity of software development that makes unequivocal results on topics like pair programming all but impossible.

Nice writeup otherwise.

Our new Product, Password Reset Server, could not wait for the .NET Framework 4.0 to be released.

Other reasons why managed code isn’t the best option:

1. Performance is sometimes an aguement. There are cases where native code will execute faster, but for the most part the difference is negligable. If you are trying to develop a real-time application, the .NET Framework may not be the best solution (then again Windows may not be the best operating system for a real-time system).

2. You still depend on the CLR. If you were to write a shell extension that depends on the CLR 4.0, and that person doesn’t have the .NET Framework 4.0 installed, they now have to install a 50 MB (minimum) package just to have a toolbar or context menu. If it gets installed anyway, that process will now start crashing (like explorer) because it can’t find the proper version of the CLR.

You would either have to install the 4.0 Framework for them, adding a hefty size to the installer, or tell them how to install it themselves.

It’ll probably be a good while before the .NET Framework 4.0 has a solid adoption and shows up in Windows Update.

3. And Frankly, while COM Interop and P/Invoke are neat – sometimes it’s just plain easier to write it in native code than write a large unmanaged wrapper.

(http://blogs.msdn.com/clrteam/archive/2009/06/03/in-process-side-by-side-part1.aspx)

Very true. I have seen most of novice dev always prefer debugging at first place – as if its lollipop. The kind of project I work for has 25+ shared assemblies (and hence that many projects), debugging is the last option I advocate for. Recommended flow to detect error is (at least what I follow):
- To have (failing) unit test
- Get some pointers from the error in the log and see if one can reach to root cause
- No luck? Please yourself with lollipop.