One of the problems with static members or static classes is that you can't mock them for proper unit-testing. Instead of taking this fact for granted, let's demonstrate it. Assume that we have the following classes (please note, this is just an example, not production code or anything that I'll be proud of later on):

public class CsvDataExtractor
{
    private string _documentPath;

    public CsvDataExtractor(string documentPath)
    {
        _documentPath = document;
    }

    public string ExtractFullName()
    {
        string content = CsvDocumentReader.GetContent(_documentPath);
        string fullName = // extract full name logic
        return fullName;
    }
}


[Test]
public void ExtractFullName_DocumentHasFirstNameAndLastNameOnly()
{
    CsvDataExtractor extractor = new CsvDataExtractor("c:\test.csv");
    
    string result = extractor.ExtractFullName();
    
    Assert.AreEqual("ellenbogen", result);
}

In my last post, I wrote about Implementing a simple multi-threaded TasksQueue. This post will concentrate in how to test for Thread Safety of the queue. Reminder: our queue is used by multiple consumers which means that I must make sure that before each Enqueue\Dequeue\Count, a lock will be obtained on the queue. Imagine that I have 1 item in the queue and 2 consumers trying to dequeue this item at the same time from different threads: The first dequeue will work just fine but the second will throw an exception (dequeue from an empty queue). We're actually trying to make sure that this queue works as expected in multi-threaded environment. So far about our goal.

So how can we test it?
Testing for the queue's thread safety through testing of TasksQueue, the way it's written now, can be quite hard and misleading. The ConsumeTask method calls dequeue inside a lock but what if we had a thread-safety-related-bug there? do we test only that the dequeue works as expected? not really. ConsumeTask (1) dequeue an item and then (2) "consume it". We're actually testing 2 behaviors\logics - this way, it's really hard to test only for the queue's thread safety. We should always test a single method for a specific behavior and eliminate dependencies. Only when we cover our basis, we can check for integration between multiple components (the underlying queue and the TasksQueue).

One way of allegedly achieving this goal is to create a decorator around the queue, let's call it SafeQueue, which will encapsulate a queue and wrap it with thread-safe forwarding of the calls (it will lock some inner object and call the original queue). The SafeQueue could be tested then by its own and used by our TasksQueue. This will "enable" us to remove the locking in the TasksQueue and use Set\WaitOne instead of Pulse\Wait in order to notify our consumers on arrival of a new task: 

while (_safeQueue.Count == 0)
   Monitor.WaitOne();

// NOTICE: by the time we get here, someone could have pulled the last item from the queue on another thread!
string item = _safeQueue.Dequeue();

WATCH OUT: This is a deadly solution that will make our TasksQueue break in a multi-threaded environment. Just like that, our code is not thread-safe anymore although we're using a SafeQueue that expose (atomic) thread-safe methods\properties. This is exactly why instance state should not be thread-safe by default (more details at Joe Duffy's post).

The locking of the queue should remain in our TasksQueue, but we should separate the dequeue part from the handling part and check each one by its own. We'll check the dequeue part for thread-safety(assuming that the underlying queue was tested by itself) and the handling part for pure logic. We can now test that for X calls for enqueue we get the same X calls for dequeue.

Here is the refactored code:

private void ConsumeTask()
{
   while (true)
   {
      string task = WaitForTask();

      if (task == null) return; // This signals our exit

      try
      {
         // work on the task
      }
      catch (Exception err)
      {
        // log err & eat the exception, we still want to resume consuming other tasks.
      }
   }
}

protected virtual string WaitForTask()
{
   lock (_locker)
   {
      // if no tasks available, wait up till we'll get something.
      while (_queue.Count == 0)
         Monitor.Wait(_locker);

      // try to put it outside of the lock statement and run the test(bellow)
      return _queue.Dequeue(); 
   }
}

Now we can create a simple test for the thread safety by overriding both of the enqueue\dequeue methods:

internal class TestableTasksQueue : TasksQueue
{
   private static int _dequeueCount = 0;
   private static int _enqueueCount = 0;

   public TestableTasksQueue(int workerCount) : base(workerCount) {}

   protected override string WaitForTask()
   {
      string item = base.WaitForTask();
      Interlocked.Increment(ref _dequeueCount);
      return item;
   }

   public override void EnqueueTask(string task)
   {
      base.EnqueueTask(task);
      Interlocked.Increment(ref _enqueueCount);
   }

   public static int DequeueCount
   {
      get { return _dequeueCount; }
   }

   public static int EnqueueCount
   {
      get { return _enqueueCount; }
   }
}

The tricky part here is the test itself. Because of subtle multi-threading issues, we can't actually know when 2 (or more) threads will try to dequeue on the same time, so we have to run this test enough times in order to detect bugs. Here is a little sample:

[TestFixture]
public class TasksQueueTests
{
   [Test]
   public void Counting_DequeueAndEnqueueCountsShouldBeEqual()
   {
      for (int j = 0; j < 1000; j++)
      {
         using (TestableTasksQueue queue = new TestableTasksQueue(5))
         {
            for (int i = 0; i < 100; i++)
               queue.EnqueueTask("test" + i);
         }

         Assert.AreEqual(TestableTasksQueue.DequeueCount, TestableTasksQueue.EnqueueCount);
      }
   }
}

Well, it's not that elegant, I know, but thread-safety is hard to test.
I would love to hear some suggestion from you regarding this issue.

In one of my tasks, I had to create a simple mechanism that will able my Team to enqueue tasks, while multiple threads will work on them on the background. I've used the Wait\PulseAll pattern in order to signal the workers when a new task is available. Here it goes:

public class TasksQueue : IDisposable
{
   private readonly object _locker = new object();
   private Thread[] _workers;
   private Queue<string> _tasksQueue = new Queue<string>();

Nothing fancy so far. Just notice that we're holding a private lock object and an array of Thread that will represent our workers.
The constructor simple initialize the threads and activate them:

public TasksQueue(int workerCount)
{
   if (workerCount <= 0) throw new ArgumentException("The number of working threads can not be equal or less than 0", "workerCount");
   
   _workers = new Thread[workerCount];
   for (int i = 0; i < workerCount; i++) { // Create and start a separate thread for each worker
      Thread workerThread = new Thread(ConsumeTask);
      workerThread.Name = "WorkerThread #" + i;
      _workers[i] = workerThread;
      workerThread.Start();
   }
}

I've bold the "ConsumeTask" method that each Thread activates. Let's see what we have there:

private void ConsumeTask()
{
   while (true)
   {
      string task;
      lock (_locker)
      {
         // if no tasks available, wait up till we'll get something.
         while (_tasksQueue.Count == 0) {
            // Monitor.Wait is equal to:
            // (1) Monitor.Exit(locker); (give others a chance to lock _locker) 
            // (2) wait for pulse 
            // (3) on pulse - Monitor.Enter(locker);
            Monitor.Wait(_locker); 
         }

         // The first working thread that will be pulsed will reacquire the lock on "locker", thus
         // it's impossible that 2 working threads will try to dequeue the same task.
         task = _tasksQueue.Dequeue();
      }

      if (task == null) return; // This signals our exit

      try
      {
         Console.WriteLine(DateTime.Now + " Start Processing task: " + task + " on thread: " + Thread.CurrentThread.Name);
         // Simulate a time-consuming task
         Console.WriteLine(DateTime.Now + "Done Processing task: " + task + " on thread: " + Thread.CurrentThread.Name);
      }
      catch (Exception err)
      {
         // log err & eat the exception, we still want to resume consuming other tasks.
         //Debug.Fail("Exception occurred while trying to consume the job (thread#: " + Thread.CurrentThread.Name + "): " + err.Message);
      }
   }
}

We're looping(infinite) and trying to see if our queue is empty - if so, we're waiting for a new task to arrive. Till then - the thread will be blocked(inactive). When we have a new task (or the queue is not empty), we dequeue a task and "process" it. Let's see the Enqueue method:

public void EnqueueTask(string task)
{
   lock (_locker)
   {
      if (task != null)
         Console.WriteLine(DateTime.Now + " Enqueue task: " + task);

      _tasksQueue.Enqueue(task);
      Monitor.Pulse(_locker); // wake 1 worker (thanks Alan) to handle the new task   
   }
}

This leaves us with disposing the all thing (killing our threads gracefully):

public void Dispose()
{
   EndCurrentWorkingThreads();
}

private void EndCurrentWorkingThreads()
{
   if (_workers == null || (_workers != null && _workers.Length == 0))
      return;

   // Signal the threads to shutdown gracefully
   for (int i = 0; i < _workers.Length; i++)
      EnqueueTask(null); //will shutdown the worker that receive a null task.

   // Wait up...
   foreach (Thread worker in _workers)
      worker.Join();
}

That's it, but how can we use it you might ask - here it goes:

using (TasksQueue q = new TasksQueue(2))
{
   for (int i = 0; i < 10; i++)
      q.EnqueueTask("Task " + i);

   Console.WriteLine("Waiting for completion...");
}

Console.WriteLine("All tasks done!");

One of the principles behind Agile Team, is the commitment of the Team to finish the planned features for a given iteration. There are times when some members in your team will finish their tasks early while others will stuck on unplanned or underestimated tasks. In a perfect world, each one of your teammates would be able to perform any kind of work whether it's design, writing database queries\commands, program, create graphic interface, test. At least to some degree. On the Agile community, these kind of people are called "generalist specialist". This will allow the Team to help each other and keep their commitment. In most of these scenarios, the teammates will help each other as a natural process of feeling as one unit. But things are more complex.

The problem is that you still want to hire a great SEO specialist, a great web designer or a great DBA, so this leaves you with the question "how could they help the Team meet its commitment?". We can't ask a SEO specialist to write multi-threaded C# code, which leaves us with a Team and a bunch of consultants that try to aid the Team hold to its commitment. I've seen this behavior of "consultants" inside teams leading to the notion of "Look, I've actually finished my tasks successfully! it was the Team that failed...".

Could we really try to use our SEO guy for multi-threading tasks? most probably not. The trick here is to find a common ground so we can bound our SEO guy into several fields, making him feel as part of the Team. For example, the SEO guy can make some web design by helping to create a SEO-correct HTML (thus helping to take some pressure off from the web designer) or maybe helping the architect design the user interface. One of the things we're doing now at our Team, is introducing our beloved DBA(Shlomo - I'm waiting for your blog dude) into writing the data-access layer in C#. We're doing it step by step, while I'm trying to explain about working methodologies and doing some pair programming. It will take us time (baby steps), but we'll get there.

This change in state of mind is not easy, but it is crucial if you want to jell your teammates into one Agile Team. Notice that I'm writing "Team" rather than "team". I see Team as a single entity, a solid force driven to hold to its commitment no matter what (while still keeping high quality delivery, of course); This is very different from a team, driven to do as much as it can, each one on its own, without being responsible for the greater good.

Being a part of something bigger is a motivation boost you shouldn't underestimate. For me, there is no bigger satisfaction than taking ownership over an entire application (instead of "I've fixed problems 1 and 2 in product A and problem 5 in product B"), working hard and making it work at the end of the day. Doing that, you could honestly say "I'm responsible for the success of our product, and I'm damn proud of it!".

Every new application we're trying to raise from scratch, especially when it's a big one, we're drawn to the basic questions of how to structure our code so it will be easy to maintain, easy to extend and easy on the eyes(= it makes sense). This post is meant for teams with more than 4 programmers working on the source of a 2+ (human) years project. If you work alone and the client doesn't really care, heck, you can do it in one big assembly and name it [your_name]Rules.

I've discovered along the years that it really bothers me to see unorganized solutions or bad naming. I call it "structure smell" and as you might have guessed, I'm a sensitive guy. I've structured my thoughts about the way I see things so I could use it later on as a reference for myself and for my Team. Before I'll continue, keep in mind that most of these questions are philosophical, so there is no one holy answer, it's just a matter of point of view. I tried to point out best practices based on my experience. In addition, instead of writing user-story\feature\requirement\bug fix\UI change\you-name-it, I would use the term "task" instead. I'll even go one step further and say that a given task should be limited to 0.5-1.5 days so it would be easy to see progress over time(if you're on the agile boat as I am) and help us focus on the domain\context we're working at during the task.

Enough said, let's get going:

"Should we build one big solution?"

The immediate answer on this one is absolutely not.
The quick reason behind it as no matter what you do, while working on a task, you usually don't need all of the projects at the same time. I see no reason to compile so many projects if you're working only on 2-3(or even 5-6) of them at a time. I know that Visual Studio .Net is smart enough to avoid needless compilation of projects that we're not changed, but keep in mind that John, your teammate, is working on different tasks than you are which means that he can make some changes, checked them in and your next "Get Latest Version" might cause unnecessary compilation on your side. If you haven't noticed(who am I kidding), VS.NET can become an heavy memory consumer for big solutions, add to it our beloved ReSharper(that must analyze all of the projects in the solution to give you smart ideas), it can get quite messy.

The second reason, is simplicity. Why looking at 40 projects when you need only just a few? sure, you can collapse them or even organize them in Solution Folders(in VS.NET 2005), but it's much easier to keep the noise out.

"So How should we split our solutions and projects?"

On this scale of projects, it would not be a great idea to create projects based on layers (DataAccess project, Business layer project, UI project etc). This way, each layer(=ClassLibrary) would be filled with too many classes and in time, it will be hard to find your path in one project with more than 200 files in it. Another bad side effect for splitting the projects by layers is that it will narrow the way you think about solutions (to problems). Instead of trying to create pure OO components you'll immediately start breaking one piece into "this is UI, this is BL, this is DAL" and possibly branch your code into the wrong assemblies by cold 0 or 1 decisions. Life is one big gray CLR.

So I'll try to define the way I see solutions, projects and namespaces and how should we use them:

1). Solution represent a domain in your application.

Domain is a complete sub-system in the application. It's much bigger than a single component and it's usually bind a list of components into one large sub-system that we can address as one big black box. The sub-system expose interfaces to other sub-systems in the application.

If I had to develop Lnbogen's Calendar for example, I would consider these sub-systems: Common, Engine, DataStorage, Site, Widgets. Each one of these sub-systems deserves it's own solution.

2). Project is a component in that domain or a mini-sub-system in the application.

A component is a all-around solution in a specific domain. The consumer of the component expect it to perform its task from A-Z even if that requires some of interaction with other objects. It should be transparent to the component's consumer. Let's say that we have a Calendar component, I would like to be able to call myCalendar.CreateNewMeeting(user, [meeting details]...) without taking care of insert it to the database, update some sort of cache(if exists) or to trigger alerts manually in case of collision. I expect the component to provide a full solution to my problem. Obviously, we don't expect the Calendar to save the meeting to the data storage by it's own but rather to receive some sort of IDataSource that will take care of it, but that should be made behind the scene as the purpose is to expose complete functionality.

In addition, a project might be "Entities" or "Utilities" where in these scenarios, the project represent a mini-sub-system.

3). Namespace group components and types under the same domain or "logic context"

Namespaces allow us to group types that are logically belong to the same domain and create a proper hierarchy so the programmer could easily find is way around the available types.

"What about naming?"

Naming is crucial for a few reasons: (A) It ables us to quickly understand the purpose of an assembly\class\method as its consumers, (B) good naming of classes\methods => less documentation => more 1:1 between your docs & your code and (C) it helps you to keep the most important principle of coding - be proud of your (and your team's) code. It's a beautiful thing to see Semingo.[...]. I'm loving it!

Naming rules:
1). Name your solutions by the domain they represent.
2). Name your projects by the components or mini-sub-system they represent. Template: [CompanyName].[Application].[ComponentName\MiniSubSystem]
3). Name your namespaces by the domain they group (the types) by.


Example (Lnbogen's Calendar):

Directories tree:

- Lnbogen
 - Calendar (root Directory)
   - build
      - v1.0
      - v1.1
      (etc)
   - tools
      (list of assemblies, exe or other 3rd party components you might use)
   - documents
   - db
      (maybe backup of database files for easy deployment)
   - src
      - Common
         | Common.sln
         - Lnbogen.Calendar.Entities 
         - Lnbogen.Calendar.Entities.Tests 
         - Lnbogen.Calendar.Utilities            
         - Lnbogen.Calendar.Utilities.Tests 
      - Engine
         | Engine.sln
         - Lnbogen.Calendar.Framework
         - Lnbogen.Calendar.Framework.Tests
         - Lnbogen.Calendar.TimeCoordinator
         - Lnbogen.Calendar.TimeCoordinator.Tests
         - Lnbogen.Calendar.RulesEngine
         - Lnbogen.Calendar.RulesEngine.Tests
         - Lnbogen.Calendar.Service ^(*1)
         - Lnbogen.Calendar.Service.Tests
      - DataStorage
         | DataStorage.sln
         - Lnbogen.Calendar.DataStorage.Framework
         - Lnbogen.Calendar.DataStorage.Framework.Tests
         - Lnbogen.Calendar.DataStorage.HardDiskPersisenceManager
         - Lnbogen.Calendar.DataStorage.HardDiskPersisenceManager.Tests
         - Lnbogen.Calendar.DataStorage.WebPersisteneceManger
         - Lnbogen.Calendar.DataStorage.WebPersisteneceManger.Tests
         - Lnbogen.Calendar.DataStorage.DatabasePersistenceManager
         - Lnbogen.Calendar.DataStorage.DatabasePersistenceManager.Tests
         - Lnbogen.Calendar.DataStorage.Service ^(*1)
         - Lnbogen.Calendar.DataStorage.Service.Tests
      - Site
         - Lnbogen.Calendar.UI
         - Lnbogen.Calendar.UI.AdminSite
         - Lnbogen.Calendar.UI.UserSite
      - Widgets
         - Lnbogen.Calendar.Widgets.Framework
         - Lnbogen.Calendar.Widgets.Interfaces (for plug-ins support)
         - Lnbogen.Calendar.Widgets.Service
         (more directories per widget)
      - Integration
         - Lnbogen.Calendar.Integration.InternalWorkflow.Tests 
         - Lnbogen.Calendar.Integration.ExternalWorkflow.Tests (test that the services we expose to the world work as expected)
      - References
         (here you should put all the dlls that you use as "file reference" in the various solutions)
         
^*1: for example, this could be WCF wrapper of the underlying engine that enable other internal components to talk with the CalendarEngine\DataStorage as one complete component.

You can notice that I've chosen to drop the "Engine" or "Common" while selecting the name of the directories. "Common" is not really a domain but rather a logic separation of things that belong to many domains (usually all of them). "Engine" is the real deal, there is no Calendar without the engine right? So in this case I feel comfortable to drop the obvious (Lnbogen.Calendar.Framework won't sound better as Lnbogen.Calendar.Engine.Framework).

Solution structure:

In VS.NET 2005, there is a nice feature named "Solution Folder" (right-click on the solution->Add->New Solution Folder) which is a lovely way to group projects. The Solution Folder is a virtual folder(you won't see it on your HD) so you don't have to get worried about too much nesting. 

Here is the pattern I love to use, demonstrated on the Engine.sln:

Engine (Solution)
   _Core (Solution Folder) (*2)
      - Lnbogen.Calendar.Framework
      - Lnbogen.Calendar.TimeCoordinator
      - Lnbogen.Calendar.RulesEngine
      - Lnbogen.Calendar.Service
   Tests (Solution Folder)
      - Lnbogen.Calendar.Framework.Tests
      - Lnbogen.Calendar.TimeCoordinator.Tests
      - Lnbogen.Calendar.RulesEngine.Tests
      - Lnbogen.Calendar.Service.Tests
   ExternalComponents (Solution Folder)
      - Lnbogen.Calendar.Entities (via "Add existing project")
      - Lnbogen.Calendar.Utilities (via "Add existing project")
   3rdPartyComponents (Solution Folder)
      - (Open Source projects that I might use will go here)
   Solution Items
      (add any dll that you use as file reference in this solution)

^*2: The reason I'm using "_" is to make sure it's the first Solution Folder. I just think it's more productive way of looking on your projects. I use the same thing for my interfaces and call the file that contains them _Interfaces.cs.

On the next post, I'll try to focus on strong naming and versioning of assemblies.

This title encapsulate a lot of changes in my life.

Leaving Mercury\HP

After less than a year, I had to make one of the hardest choices in my life and decided to resign my position at Mercury after receiving an opportunity to join a baby(we're looking for offices now) startup named Semingo. Mercury is a great home for developers; The quality of the people there is beyond anything I've seen in the last ~8 years, the projects are challenging, the clients are demanding and the amount of investments the management put in the teams is unimaginable. No wonder why Mercury was bought for the huge price of 4.5 billion dollars by HP. Putting the clients first, hire great managers, non-stop training and fetching the best programmers available is a bullet-proof path for success.

The hardest part was leaving my friends there, but I know that I'll keep in touch with them. I said goodbye to the guys in a small gathering so I want to leave it private, but I do want to thank you all again for sharing your life, your ideas and challenges with me:
Hagay, Number, Big Guy, Jersey, Nicos, Rico, Master Jedi(Doron), Moti, Jonit, Chonga, Maya, Mininberg, Alon, Chik Chik, Abergel, Oleg, Mizrahi, Ravit, Sefi, Lidor, Zini, Arie, Ifat and the rest of the guys there(I hope I did not forget anyone :|) - goodbye and good luck. I love you all.

Joining Semingo

This was an offer that I just could not say no to. The project is inspiring, the scale and size are unimaginable, the team is built from a group of young(avg. ~25) "hackers"(my nickname for highly talented workaholic developers), great technology, great management. All the right cards. In addition, and this one is crucial - I'm 23 years old so this is a great(maybe the only) time to work 14-18h a day without paying alimony\psychotherapist. I'm sure that it will be very interesting ride. 

At the moment, I can't say much about the stuff we're doing except that it's a very challenging web 2.0 project.
I promise to publish more about the team, work methodologies(agile\scrum) and technical experience later on...

Leaving my home, renting an apartment:

I'm looking for an apartment in Herzelia\Herzelia Pitouch, close to the our future office. If you know a guy that knows a guy - please send me an email! ;)

Gosh, it's going to be one hell of a year!

I had just resolved a very ugly bug in one of our screens. The behavior was the following:
You open a the page and click on a "cancel" button that closes the current screen and refresh the parent screen.
So far all is sweet.
Now you do it again (open & click "cancel")
So far all is sweet.
Try to open any other page.
gosh! nothing works! Everything got stuck somehow...

The cancel button was declared like this:

<asp:Button id="..." runat="server" OnClientClick="RefreshParentAndCloseMe();" />

Can you spot the problematic approach here?
Button.AutoPostBack is set to True as default which means that clicking on the button triggered page submit but at the same
time we run javascript code to close the window. My guess is that the server gets a new request and handles it but the client
is dead until then(until the response is ready).
Playing with this behavior can lead to unexpected behavior (in our case - we had to close the browser and start over)

Solutions?
  A. Use html button (I prefer this one as this pure client behavior button)
  B. change the OnClientClick to: OnClientClick="RefreshParentAndClose(); return false;"
  C. Set AutoPostBack=False on the button.

Damn, it was so much fun to play a little with TDD and abstract the lousy API given by Microsoft to register client-side script. I'll write about the process and design changes I've made due to testability reasons. TDD is a great design tool, it's amazing to witness the "before" and "after" of your code, all because of the requirements to test things separately.

Here are a few API samples, taken from the Demo project (you can play with it and see the results):

Keep in mind that I'm only supplying a different API (abstraction) of Microsoft's implementation. In order to accomplish that, I'm using Windsor to wire the ClientSideExtender with the new ajaxian ScriptManager(supports UpdatePanel), which will actually be responsible to register the script under the hood. You can look at the web.config (under the <castle> element) for more details.

Source:
Lnbogen.Web.UI.zip (253.56 KB)

Thank God, some may say, that bananas are still way too expensive to replace human developers with apes; Well, at least by Uri Kalish in his Why Software Engineers Should Care About the Price of Bananas. Let's face it, we have too many "chumps" out there, lurking to make a few extra bucks by faking it really well. But every once in a while, the sun is shining in glorious colors and you meet a really talented developer whom you think will be a great addition to your team. You ask her logical questions, she shoot right back with pearly answers; You ask her to design something and bang, she nails it; You ask her to juggle with code a bit and it is all sweet. She has analytic mind and just enough experience. Total Package.

This leaves you with the one thing, the only thing, that really matters - how can you tell whether or not she will use her analytic mind to solve your team's problems instead of introducing more complicated ones while trying?

I came to the conclusion that the only way to know how skilled a developer is, is by letting her solve a very simple problem and shoot more problems to the air while she solves it. Skilled developers will be able to break things into smaller chunks and solve them in a SIMPLE manner. When I say simple, I mean it, it will be so simple taht even a chump will be able to read it. Then they will move on to the next problem and solve it in the same SIMPLE way they did before. Then they'll tell you how to sew the all thing into one wonderful solution. It's actually pretty straightforward, simple things are easier to combine, but only a few folks out there knows how to "break & build" in a graceful, simple manner.

I look way back to my first days with .Net and OOP and I can honestly say that I did it all wrong(although it looked damn right at the time). If you looked at the code, it was elegant, in its own way, it was "sophisticated"(interfaces, events, a few Design Patterns) but it wasn't right. It wasn't SIMPLE. I had too many classes with too many (wrong) responsibilities, some of them contained quite a few God Methods and they were in no way testable. I had a great amount of green words(aka comments) to explain why things "needed" to be complex.

So for the developers among you - read, talk, write, teach and most importantly practice. Continue to improve your skills by breaking tasks into smaller chunks and keep making them green-free. If you spend more lines on documentation, you're on the wrong direction. Invest time in breaking responsibilities to different classes(class should have a very narrow responsibility) and take the time to think about your API. I'm playing quite a lot lately(Fluent Interfaces, Creating a decent API for client side script registration) with method names and the benefit I see in it is huge. readable API requires almost no documentation at all. Adding testable code to the equation and you're definitely on the right track.

For those of you out there that interview people - if you think this is it and you finally found someone - let him\her solve a few problems and focus about how simple is it to read the code, to refactor it, to extend it. How much documentation is required to explain the solution to the rest of your team?

What do you look for when interviewing skilled developers?

Phil Haack gives an excellent example of how to test a registration to event while implementing MVP pattern (via Rhino Mocks). If you did not read it yet, take a pause for 2 minutes and give it a look; It is worth it, I promise.

The only thing that bothers me in the example is that the need to assert the triggering of the event kind of spoiled the code. I think that in those scenarios, it's much better to use some sort of Stub and override the class under test in order to keep the it cleaner. So instead of having this code:

public class Presenter
{
   IView view;
   public Presenter(IView view)
   {
      this.view = view;
      this.view.Load += new EventHandler(view_Load);
   }

   public bool EventLoaded
   {
      get { return this.eventLoaded; }
      set { this.eventLoaded = value; }
   }

   bool eventLoaded;

   void view_Load(object sender, EventArgs e)
   {
      this.eventLoaded = true;
   }
}

I would have created something like this:

public class Presenter
{
   IView view;
   public Presenter(IView view)
   {
      this.view = view;
      this.view.Load += new EventHandler(view_Load);
   }

   protected virtual void view_Load(object sender, EventArgs e)
   {
       // production code here
   }
}


// This will go in the PresenterTests class
public class TestablePresenter : Presenter
{
   public bool WasEventLoaded = false;
   protected override void view_Load(object sender, EventArgs e)
   {
       WasEventLoaded = true;
   }
}

Now we can create an instance of TestablePresenter and Assert the WasEventLoaded field.
My guess is that Phil actually did something like this in his project and merely wanted to show an example, but I still thought it was important enough to demonstrate this separation as I firmly believe we must make sure that our need for tests will not actually hurt the design.