Place your cursor on the class declaration

Press Alt+Ins to get the code generation menu up from Resharper. Select Overriding Members. Select from the list, the members you want to override

Hit Finish!

I read a post today about how there should be a plug-in for Visual Studio to disable copy/paste, in order to prevent people from copying and pasting the same code over and over again, instead of applying basic design principles (DRY). Now I'm sure the author didn't mean this in a serious way (it's hell to be without copy/paste, and if you don't believe me, use the iPhone for a couple of days), but it reminds me of recent discussions about RhinoMock vs TypeMock, or put another way, TypeMock vs every other mocking framework out there.

The main discussion was that TypeMock could lead to malpractice. By using TypeMock, people could potentially end up with tightly coupled code. Since there isn't a need to inject dependencies, you could create dependent objects in your classes. I posted my thoughts on this a long time ago (too far back for Live Writer to show it up in recent blog posts), so I'm not going to get into too much detail, but suffice to say, I didn't agree then and I still don't agree now.

But what has that got to do with the copy/paste post you might be asking yourself. Well I think in both cases, we are showing signs of wanting the tool/framework to do the work for us, to police us, so to speak. Which begs the question, why?

I work on a team, as a tech lead. The part about work is questionable, but nonetheless I am on a team. Part of my job is to oversee my team and make sure that things are being done correctly. In my book, correct means applying good design principles. It is my job to make sure that my team applies these principles. If a team member is new or is not familiar with certain concepts, it's my job to teach them to him/her. With new team members, there is normally a period of code-review, where during check-ins code is reviewed by senior developers (either myself or someone else on the team) to make sure that they comply not only with design principles but standards of coding and practices. However, as time elapses, code reviews become less frequent (although there should always be peer review on a team from time to time). So initially it might be a time-consuming job, but in the long run it isn't. In many cases it's also very productive since there's always something new you can learn.

If people are taught things in a way, that not only do they understand, but see what happens when they do it the wrong way, they will act correctly.

Developers are not stupid.

In my previous post, I talked about confidence and how it plays an important role in the adoption of SCRUM. The next aspect of a team, specially the smaller ones, is that the majority of the team members need to be multi-disciplinary, in other words, need to wear multiple hats.

A Scrum project is divided up into sprints which can be anywhere between 2 and 4 weeks (ideally). Before each sprint, there is a planning stage, where items are taken off of the product backlog and planned for the sprint (I'll talk about how we plan in another post). Once the number of items are selected, the sprint starts and team members start to work on them.

Now here's one important detail: in true Scrum, and that is Scrum that really works, there is no task assignment. The Scrum master does not assign tasks to team members. Tasks are self-assigned by those who work on them.

From a perspective of a team leader, be it a technical lead or project manager, this might not seem such a great idea at first.

How can I be sure people will get things done?

How do I know how much Joe has done and how much Jack has done?

What if John is pulling all the weight?

Obviously, as members assign themselves tasks when working on them, all these questions are answered in the first sprint. But here's a more difficult one (which recently came up in a conversation with a colleague):

What if Jack is taking all the easy tasks...it's human nature to be selfish and aim for the least effort

In my book, it's not human nature. And in my book, Jack has no place on my team. In other words, if you have a team member like Jack, get rid of him. You don't need him.

This self-assignment of tasks and not having to micro-manage people (which is always a good thing), brings on another issue: you need multi-talented people. In the same way a project can fail if your bus number is low, a sprint can fail and consequently your whole project can get delayed because of the same issue. When a sprint is planned, and all members have agreed on a list of tasks to work on, these are regularly categorized, be it due to technology, business or any other factor. People tend to stick to a certain category. If Joe has been working on the back-end, he tends to pick tasks that are related to that area. If John is working on reporting, he'll pick out tasks of that nature. This isn't necessarily a bad thing, unless it becomes pathological. What cannot happen is for Joe to refuse to work on something that is not directly related to his area. If Joe runs finishes his tasks and he only sees a list of tasks that fall out of his area, he needs to be able to jump in and grab one of them. Otherwise, the task remains there until John, the "owner" of that area can work on it, who happens to be working on a previous task. What is even worse is if Joe does have a task in his area, but that it depends on another task which is not in his area.

What ends up happening is that John is causing a bottleneck. The time that Joe is waiting is ultimately time that is lost, which in turn is translated into a delay and consequently a failure of the sprint.

Therefore, it is very important for team members to have the knowledge, and more importantly, the confidence to confront different situations and take on various tasks. This doesn't mean that they have to do it alone. One of the jobs of a Scrum Master is to remove impediments, and if an impediment is caused by a lack of knowledge, the scrum master, one that also needs to be multi-talented has to act as a mentor and lead, has to guide team members through the different challenges.

Scrum doesn't work if you sit around for the next guy to get rid of your problem.

Many of us have been solo developers for many years. I personally started working on customer projects as a one-man show. I was in charge of talking to the customer, gathering requirements, giving estimates, developing, testing and delivering the project.

My "guesstimation" process consisted of taking the requirements, breaking them down into tasks that I could somehow measure in terms of hours. This worked well for me. As time passed I got better at my guesstimates until they actually turned into estimates. I would end up with a task list like so (invented values):

Once I had the total number of weeks, I would then commit to doing x tasks per week, based on difficulty, priority, etc. At this point, the hours would completely fall out of the picture. I didn't care how many hours I had assigned to Customer Management. All I cared about was that I needed to get it done by a certain date (iteration).

As I would work on tasks, I wouldn't keep track of the number of hours I had worked on them. I would keep in my mind a global vision of how the whole process for that particular week was going and based on my progress I would know if I was going to reach my objective or not (burndown). If I was late, I would normally update my list of pending tasks and try and re-plan things for the next run. But again, I wouldn't keep track of how many hours I had worked on a particular task.

Does this sound familiar? I'm sure many of you who have worked solo have done something along these lines. I wasn't doing anything special.

So what has all this got to do with Scrum? In Scrum, the team works together to come up with a list of tasks they can cover in an iteration and get to work. They monitor their overall progress using the sprint burndown chart to make sure they'll reach their objectives. Tasks are marked as done when they are done. Team members don't have to specify how long it took them to get the job done, just like myself, as a solo developer never (not even once) wrote down how many hours it took me to work on a specific task. Does this mean that tracking the number of hours worked on a task should never be done? No. There are reasons for doing so at certain stages, but that's a topic for another blog post.

So if you think about it, all scrum is, is a bunch of solo developers working on a team. It seems simple, yet it isn't. Scrum isn't always successful. There are many reasons for it to fail, but nearly all of them stem from the same root: confidence. As a solo developer, I am not only the producer, but the stakeholder. If I don't do my job, my customer won't pay and it all goes to hell. I need to rely on myself. I need to have confidence in myself.

However, when working on a team, it's much harder to build up the confidence. Each team member not only has to have confidence in himself, but to have confidence with all members of the team and to be able to rely on them. There needs to be an understanding that it's no longer about individuality but about a team. If one fails, the team can fail. If the team succeeds, everyone succeeds.

There are many other factors that can contribute to a successful team and project and I'll be covering some of the things that I think are vital in later posts, but the first step is to build up the confidence in the team. 

Testing for exceptions in unit tests can be tricky. Most frameworks use the ExpectedException attribute to denote that the test will pass when a specific exception is raised. As an example, let's look at the following test:

   1: [TestMethod]

   2: [ExpectedException(typeof(AuthenticationException))]

   3: public void Authenticate_With_Invalid_Credentials_Throws_AuthenticationException{

   4:  

   5:     AuthenticationServices services = new AuthenticationServices();

   6:     

   7:     services.Authenticate("user", "wrong");

   8:     

   9: }

In many cases this works. If you are throwing a custom exception, then the chances of the same exception occurring in your code in the wrong place are minimal. However, things change when you are testing for system exceptions. Imagine in the previous example if we were to throw a SecurityException instead of AuthenticationException. The .NET framework could throw a security exception itself due to some specific reason. As far as the test is concerned, it passes because it doesn't care who or where the exception is thrown. It just cares that it's happened.

An alternative approach to this would be to wrap the specific call in a try..catch block and not use the ExpectedException attribute.

The guys that designed xUnit understood the shortcomings of testing exceptions and took a much cleaner approach. In xUnit, the previous test would be written like so:

   1: [Fact]

   2: public void Authenticate_With_Invalid_Credentials_Throws_AuthenticationException()

   3: {

   4:     AuthenticationServices services = new AuthenticationServices();

   5:  

   6:     Exception ex = Assert.Throws<AuthenticationException>(() => services.Authenticate("user", "wrong"));

   7:     

   8:     Assert.Equal("Authentication Failed", ex.Message);

   9: }

As you can see, there is no ExpectedException on the test (called a Fact in xUnit). Instead, the Assert.Throws construct is used. This is a generic method that takes a type parameter the type of exception we want to check for. As parameter we pass a delegate or lambda expression with the actual call that will throw the exception.

The obvious advantage to this is that if any other part of our system were to throw the same type of exception, our test would fails, as it should. So instead of creating a custom exception we were to use SecurityException and on creation of AuthenticationServices the framework would throw a security exception, our test would fail.

Another advantage of Assert.Throws is that it allows you to examine the returned exception object, so you can run further assertions on it (like that on line 8).

Note: While I was doing my Unit Testing session at Devreach this week, someone asked me how to test for two exceptions within the same call in Assert.Throws. You don't. Each test should check for only one exception. Remember, a unit test only tests one thing, one situation. If your code is throwing two different exceptions, it's can't be doing it under the same conditions.

Arrived yesterday from the Software Developer Conference near Amsterdam. Excellent conference and a lot of fun. They really know how to take care of speakers.

I'm heading off to Devreach in Sofia tomorrow and then from there on to Madrid for the ALM conference. If you're going to be around in Madrid, make sure you stop at our booth, we have some cool goodies to give away. Then I have around nine days I get to not travel before the next round of events start.

Well Marco's probably been the first one to blog about it. My only comments are:

a) Change the name. PRISM is already a pretty well-known project in the Microsoft camp, also known as Composite Application Library for WPF/Silverlight

b) Two years ago I said at a session at TechEd that going down the VCL.NET route is a mistake because of the lack of roadmap and support from third-parties. I received a lot of feedback (i.e. read hate mail). Ironic...

I had a short talk yesterday on ASP.NET MVC. For someone that has been developing using ASP.NET and seeing ASP.NET MVC for the first time, has an immediate reaction of "we're going back in time, we're heading back to spaghetti code". And it's understandable. What would be your first impression if you saw something like the code below in an ASPX file?

   1: <%foreach (Customer customer in ViewData.Model)

   2:   {%>

   3: <tr>

   4:     <td style="width: 98px">

   5:         <%=Html.ActionLink(customer.Firstname, "Edit", new { id = customer.Id}) %>

   6:         &nbsp;</td>

   7:     <td style="width: 112px">

   8:         <%=customer.Lastname %>

We've moved on several years and the best we could do was replace a for loop with a foreach?

But ASP.NET MVC isn't about going back to unreadable code. It's the exact opposite. MVC is about separation of concerns. For those not familiar with the MVC Movie, three actors participate: The Model, the View and the Controller.

Model: The business model, the data, the domain logic, whatever you want to call it. It's responsibility is the model and everything to do with the model.

View: The user interface. It displays and collects information. It's entire responsibility is to display the information and to receive information from the user.

Controller: Middleman. It's job is to coordinate between the Model and the View. It gets information from the model and provides it to the view. It receives information from the view and passes it back to the model. It takes care of any logic that has to do with both parties involved.

To put it in other terms, the Model is the property owner, the View is the guy that wants to buy the house. The Controller is the notary. It coordinates the actions between the two parties involved. It's not there to make decisions for the owner or for the buyer. It's an neutral entity (that gets paid way too much IMHO, but that's beside the point). Without one of the parties, the notary has no reason for existing.

[Note for the purists: this is not the strict MVC architecture defined in Smalltalk where the View had access to the Model]

Going back to the previous code and looking at what it's actually doing, we see that it's only looping through a list of customers and display the information. In other words, it is not stepping out of it's boundaries. It's not trying to take on other responsibilities. However, having said that, nothing stops us from doing other things in the code. If we have access to the model, we can start doing some nasty things by delegating the responsibility of a controller to a view and let the view start deciding when and how something should be displayed.

The developer: the forth actor

There are really four actors in ASP.NET MVC(D). You need to apply good design principles and truly understand what single responsibility and separation of concerns means. Don't think for a moment that you are safe just because you're using a framework, pattern or architecture.

On Steve Martin's blog