In my last post, I mentioned that I think that hand rolled data access layers using stored procedures are a bad thing, and one of my co-workers asked me to elaborate.

The main reason that I don’t like hand rolled data access layers is that by writing your own DAL, you are basically reimplementing a solved problem. Think about all of the things you have worry about if you write your own DAL:

• Creating the CRUD stored procs
• Writing ADO.NET code to call the stored procs
• Figuring out which entities are dirty and need to be saved, and which properties have changed
• What relationships do you load when you load an entity from the database? How do you do lazy loading of relationships?
• Writing tests to test all of this custom code that you have to write

There are numerous object-relational mapping (ORM) tools out there which take care of all of this. NHibernate is my favorite (more specifically, Fluent NHibernate). NHibernate has been around for several years and is very mature. There are ORMs from Microsoft (LINQ to SQL, Entity Framework), and numerous other ORMs out there.

These ORMs have thousands of people using them, so they have been well tested and have proven over time to be very effective at what they do. Countless hours have gone into the development, design, and testing of these ORMs.

Think about what you are trying to do by writing your own hand rolled data access layer. Who are you to think that you can do a better job in a short amount of time than the people who developed these mature solutions over several years? Data access is a very complicated thing to try and implement, and some of the most painful code that I’ve ever had to deal with was found in someone’s hand rolled data access layer.

Here’s the thing — a large percentage of your data access is vanilla loading and saving of objects from the database. In these cases, performance is not a concern and you do not need any special queries in order to optimize the loading and saving of these objects.

For a very small percentage of your data access, performance may be a concern and you may need to use custom stored procedures. So in these cases, you can bypass the ORM and write your stored procedures and custom code in order to optimize the loading and saving of these specific objects.

If you use stored procedures and custom code, you have more control over things. This also comes with a cost (longer time to develop). If you are accepting this cost for cases where you don’t need to optimize the data access, I would say that you’ve wasted time on premature optimization, not to mention that you’ve probably had to spend time implementing all of that data access code.

I would rather use an ORM that has implemented everything that is difficult about data access. Now all I have to tell it how to map to the database (which isn’t that hard) and tell it to do things for me. With lazy loading, it won’t load entity relationships (e.g. child collections on an entity object) unless it needs to. It knows when objects are dirty and if they need to be saved or not. I have an easy hook so that I can validate entities when they are saved.

The other day I configured a cache in NHibernate in 15 minutes. With very little code I was able to set NHibernate up so that it will cache entities that don’t ever change in memory so that it doesn’t have to get to the database to get them every time. There were numerous examples on the internet telling me how to do this, and I’m extremely confident that it’s going to work (I didn’t have to write any of the difficult code for caching because NHibernate has solved that problem).

I want to write code that solves business problems. Thankfully other people have written libraries that will help me do that. So I’m going to use them.

I finally broke down, set aside some time, and learned Ruby on Rails. My previous experience had been the Ruby Koans, random discussions with people, and a couple quick demos. So basically I knew Ruby, but not Rails.

I started by reading through Rails For .NET Developers, which was an excellent book. Normally I don’t read a lot of tech books (I’m more of a blog guy), but when I’m learning something new, I like having something that will walk me through it. This book did an excellent job of it.

So I had a basic web site with a couple pages and I started building it. I used RSpec for my testing framework and I wrote my tests first, of course.

I was surprised at how similar Rails development is to ASP.NET MVC. Certainly the language is different, but you’re using the same MVC pattern, you’re writing tests for the same things, and you’re creating views in pretty much the same way. I knew that the .NET community had borrowed a lot from Rails, but I got a first hand view of it. I was glad to know that my world wasn’t going to be turned upside down.

The main thing that I noticed is that with Ruby on Rails, it’s really easy to hit the ground running. You have most of what you need out of the box with Rails, and you can easily install more gems to provide extra functionality. It’s all so easy and there is very little friction.

I’ve been doing .NET for awhile now, and I feel that I have a pretty good understanding of it. I’ve learned a lot of tricks and I use a lot of open source projects and other Microsoft libraries to add functionality to .NET, similar to how you add gems in Rails. I written code myself that does database migrations (like rake db:migrate) and code that runs builds (like rake… I’ve even used rake in .NET). But there several significant differences — first, I had to know about the open source projects (and I suspect that many people don’t know about some of them, or worse, aren’t allowed to use them). Second, I have to download them and set them up myself (and know how to do it). Third, I had to write some of the code from scratch.

I think the point I’m trying to make in that last paragraph is that someone who is new to .NET could not grab ASP.NET MVC and have everything they need to create a really good, frictionless, ASP.NET MVC app. When I did my Rails app, I already had my ORM, database migrations, build runner, and my project structure was set up with a lot of code generated for me.

The other benefit to this is that most Rails developers will most likely be doing things the same way. If you do Rails, you’re going to be using an MVC framework, you’re going to use ActiveRecord as your ORM, you’re going to use rake, you’re going to have the same project structure, and on and on. In the .NET world, there are so many different solutions out there. Not that they are all bad, but consistency makes it easier to find someone else who does things your way. In the .NET world, a large majority of developers are still using stored procedures to do all of their data access, and if you are using an ORM, there are many different ones that you might be using. Again, this isn’t necessarily a bad thing (although I would argue that hand rolled data access layers using stored procs are a bad thing), but I feel like there is value in consistency.

I feel that Rails development is very tempting to many developers in the .NET community. This isn’t all because of the language, it’s also because ideas and practices like TDD, the MVC pattern, and good design practices are much more widely accepted in the Ruby community. There is a lot of good in the .NET community, and I still think that .NET is a great platform for building all kinds of applications. But I feel like things like TDD, ORMs, the SOLID principles, etc. are used by less then half of .NET developers out there. Once you start using things like ORMs and TDD, it’s really difficult to join a project that doesn’t use these things and be productive.

So the moral of the story is to use whatever tool you can find to best do the job. Ruby on Rails is something I wouldn’t mind having in my toolbox.

One question that I hear from people who are new to TDD or writing tests is, “How much longer is my feature going to take if I write tests?” This is a valid question. We all have deadlines, so if we have to add something extra to our development process, it better be worth it.

I don’t think I could say it better than this post did, so I’ll just let you read it for yourself.

A lot happens from the time that a business owner envisions an idea in their mind and the time that the idea becomes software. The trick is getting through the whole software development process without losing the original idea.

Have you ever played that party game when you go around the circle whispering the same phrase and when you get to the end the phrase is completely different than when it started? Software development ends up like that a lot (especially when the business owner is changing the original idea!).

The problem is that we all speak a different languages. Developers speak one language, BAs another, PMs another, DBAs another, users another, business people another, executives another, and so on. So a large part of our job is learning how to translate what these people want into developer language (code), and doing it so that, in the end, the software speaks to them in their language.

Here’s a simple example:

Executive: “When we hire new employees, we need to make sure that they have a computer ready for them when they start.”

Business analyst: “User will enter the number of new employees on the screen. The system will check the inventory and make sure that we have enough machines, monitors, keyboards, and mice for the new employees. Each employee should have two monitors.”

Now it’s our turn. As developers, we have to do several translations in the process of writing the software. The DBA (or you) may have to design the database schema. You (the developer) have to write the code.

Remember, the goal is to not lose the original idea. That means that each time we “translate” the original idea, we need to do it little bits at a time.

Usually business analysts don’t give you specs that are written exactly how you want them. This is not a knock on BAs, but they speak a different language than us developers. What we really want from them is a set of acceptance criteria. In other words, we need to know what we have to do in order to complete the feature. Not only that, we need to know how we are going to test our feature so that we know that it’s working.

So let’s take the business analyst’s specs and translate them into acceptance criteria:

Given a stash of unused hardware
   When a user enters the number of new employees
      Then it should verify that we have one machine for each new employee
      Then it should verify that we have two monitors for each new employee
      Then it should verify that we have one keyboard for each new employee
      Then it should verify that we have one mouse for each new employee

   When we don’t have enough mice for new employees
      Then we need to order new mice so that we have one for each new employee

We’re not saying anything drastically different from what the business analyst said. But the way that we wrote it is important. Notice the use of the words given, when, then. Here’s the next translation:

public class Given_a_stash_of_unused_hardware
{
}

public class When_a_user_enters_the_number_of_new_employees 
    : Given_a_stash_of_unused_hardware
{
    [Test]
    public void Then_it_should_verify_that_we_have_one_machine_for_each_new_employee() 
    {
    }

    [Test]
    public void Then_it_should_verify_that_we_have_two_monitors_for_each_new_employee() 
    {
    }

    [Test]
    public void Then_it_should_verify_that_we_have_one_keyboard_for_each_new_employee() 
    {
    }

    [Test]
    public void Then_it_should_verify_that_we_have_one_mouse_for_each_new_employee() 
    {
    }
}

public class When_we_don't_have_enough_machines_for_new_employees 
    : Given_a_stash_of_unused_hardware
{
    [Test]
    public void Then_we_need_to_order_new_machines_so_that_we_have_one_for_each_new_employee() 
    {
    }
}

public class When_we_don't_have_enough_monitors_for_new_employees 
    : Given_a_stash_of_unused_hardware
{
    [Test]
    public void Then_we_need_to_order_new_monitors_so_that_we_have_two_for_each_new_employee() 
    {
    }
}

public class When_we_don't_have_enough_keyboards_for_new_employees 
    : Given_a_stash_of_unused_hardware
{
    [Test]
    public void Then_we_need_to_order_new_keyboards_so_that_we_have_one_for_each_new_employee() 
    {
    }
}

public class When_we_don't_have_enough_mice_for_new_employees 
    : Given_a_stash_of_unused_hardware
{
    [Test]
    public void Then_we_need_to_order_new_mice_so_that_we_have_one_for_each_new_employee() 
    {
    }
}

This is how you do behavior driven development. We took our acceptance criteria and wrote them out as code in the form of unit tests. These unit tests will prove that our code is working (when we get to that point) and it will also act as our documentation of what the code is supposed to do.

The reason that this is important is that we’re still in the middle of doing our translation. A lot of people take the tech specs and immediately start writing implementation code. But by doing that, you skip a step in the translation, and when you do that, you risk losing some of the original intent of the feature. This is one of the reason why writing tests before you write implementation code is important. First of all, if you write your tests first, then when they’re passing, you know that you’re done. Second, you’ve written out what the feature is supposed to do — nothing more, nothing less. This is going to help us implement the feature without losing the original intent of the person who thought it up.

Now, yes now, you can go write the implementation code. By focusing on what the end product should be and since you wrote your tests first, this part should be easy. It’s much easier to achieve your goal when you know what the goal is!

90+ people showed up yesterday to learn loads of good stuff about OOP, SOLID, code metrics, production debugging, and TDD. Judging from the barrage of tweets that I saw today, I’d say the event was a smashing success!! I’m glad to see that so many people found that it was worth spending their day learning about such good stuff.

Props to Jim Holmes, who came up with original idea and did most of the leg work. He won’t take the credit, but he deserves a lot of it.

If you’re looking for the slides from my SOLID talk, you can get them here. (If you’re in Dayton, you can come see me give my SOLID talk at the Dayton .NET Developers Group on October 28!)

I’ll be speaking on the SOLID software design principles at the Quick Solutions office (440 Polaris Pkwy., Suite 500, Westerville) on Wednesday, Sept. 16 from 5:30pm-to 7pm. In this talk, we’ll go through Uncle Bob’s “SOLID” software design principles, separation of concerns, a brief overview of inversion of control containers like StructureMap and Ninject, and more object-oriented goodness that will help you write better code.

There’s free food too. If you’re coming, please RSVP to amorey at quicksolutions dot com so that we can have enough food.

If you’re going to the Software Engineering 101 conference, this is basically the same talk that I’ll be giving there. So if you’re going to go to one, go to the Software Engineering conference since you’ll get lots of other good stuff there too.

I’ve been a big sports fan every since I was a young kid, and one thing that always amazes me is how much emotion plays a part in pretty much every sport. For example, in the NBA last year, the home team won 60.8% of the time. If a team were able to block out emotion on the road so that they played as well on the road as they do at home, that would be a huge advantage.

Emotions affect software developers too. I didn’t really think about this so much until I noticed how I was going about things on my current project.

I’m working on a project by myself for a company that has no IT department. So I have to do all of the requirements gathering, design, development, testing, and deployment. I got all of my requirements, I estimated everything out, and I have an Excel spreadsheet where I keep track of how much work I have done and how much I should have done by this point.

I feel like I check that spreadsheet every day to make sure that the number of days of work I’ve completed is higher than the “where I should be” number. Now this isn’t all bad, it’s good for me to know where I’m at and if I’m behind. But this obsession is leading to other odd behavior.

For example, I’ve had the server I’m going to deploy on for months and I keep putting off setting it up. I didn’t conciously think this, but setting up the deployment server wouldn’t make my “hours finished” number go up in my spreadsheet, even though I obviously have to set up the deployment server sometime. So because I wanted to bump up my “hours finished” number, I would do feature development.

A couple weeks ago, I had a couple features drag on several days past the estimate I had for those features, and that was a really hard week. Not because I was in real danger of getting behind, but I was week ahead of schedule in my spreadsheet before the week and I was right on schedule after the week (I didn’t get to cross anything off that week). I felt stressed out all week.

Why was I so upset? I wasn’t even behind schedule! In reality, I ran into a feature that took longer than the estimate, while earlier in the project I had features that took less than the estimate. It really shouldn’t be a big deal.

I realized that I am addict — an addict to getting things done. We all want to be able to cross a feature off the list, and we feel like we haven’t accomplished anything on the feature until we do so.

If you want to see what a developer under pressure, watch what happens when the amount of time they’ve spent on a feature exceeds the estimate. I’ve seen developers get extremely flustered in this situation. They get irritable, they worry that someone is looking down on their performance, and often they cut corners. And for what reason? Because of an estimate, just a guess of how long something is going to take!

An estimate should have no effect on how long a feature should take. If a feature is going to take 3 days to develop, it doesn’t matter if it were estimated at 1 day or 15 days, it’s going to take 3 days. Period. If you stop writing unit tests once you’re over the estimate just to get it done, you’re doing everyone on the project and yourself a disservice.

The addiction to getting things done manifests itself in other ways. I’ve seen situations where developers could’ve spent 5 minutes installing a tool or an update that would’ve saved them loads of time over the course of a project. But they feel like they’re too busy to stop for 5 minutes and install it, so they continue doing it the slow way. These are completely logical people making very illogical decisions.

Other people won’t take the time to learn a new tool or a new technique like TDD because they would have to slow down to learn it. Sometimes this is valid (we all have deadlines), but if you honestly think that something might be able to save you lots of time in the long run, isn’t it worth spending a couple days looking into it? It might work out, and it might not. But if it doesn’t work out, all you’ve lost is two days, and if it doesn’t work out, it might revolutionize the way you write software.

I guess my point is be aware of your emotions and how they affect the way that you work. Don’t let your emotions control you and cause you to make illogical decisions. And please remember, that an estimate is just that — an estimate!

In case you haven’t heard, the Software Engineering 101 Conference is going on in Columbus on September 23. This is a one-day event where you will learn about software design topics and techniques such as object-oriented programming and the SOLID software design principles as well as a super-special hands-on test driven development session! This is all good stuff that every developer should know and it will be well worth your time. Rather than recount all the details, I’ll let you read more on Jim’s blog.

This is a FREE event, so all you have to do is ask your employer if you can go, they don’t even have to pay anything for it. I feel like I say this a lot, but these skills are essential for any software developer and have revolutionized the way that I write code.

Registration is limited, and I expect that it will fill up relatively soon, so don’t wait! You can click here to register.

Most of us at some point have decided that we want to learn some new technology. The question is what you should dive into.

When I interview people, I always ask them about new things that they have been learning, and a lot of people these days are looking into things like WPF and Silverlight. But this is not what I would pick if I were you.

If you were to ask me, instead of learning some new technology, every developer should try to become experts in software design patterns and principles and practices that will help you become a better developer with the technologies that you already know. Our industry has a much bigger need for developers that write well-designed, loosely coupled, well-tested code than we need for people with a basic knowledge of WPF or Silverlight.

Look, there’s nothing wrong with learning WPF and Silverlight, and you can make some awesome looking apps with them. But if you can learn software design patterns and practices, those will help you when using any language for the rest of your career. They will help you write less bugs, they will help you get stuff done faster, and they will help you write flexible code that can easily be changed. Who doesn’t need more of that?

Like I said, I interview people. If I interview you and you know and practice things like test-driven development, the SOLID principles, what the Law of Demeter is, and why all of this matters, then you are most likely in (as long as there isn’t something else seriously wrong with you). In my opinion (and this is just my opinion), if you want to be called a “senior developer” I would expect you to know all of these things. This is much more important than how many years of experience you have.

This may require some research and leg work on your part. I say this because in my opinion, Microsoft doesn’t not actively promote this stuff. Sure, you might find some MSDN article out there that talks about testing or patterns or something like that, but there will probably be many times more articles about Silverlight, new features in .NET 4.0, and the like. All of that stuff is good, but I feel people are skipping over the essentials. You can probably pass any number of Microsoft certification tests without knowing much about test driven development or design patterns.

This is why I identify with the ALT.NET way of thinking. ALT.NET generally believes in these principles:

1. You’re the type of developer who uses what works while keeping an eye out for a better way.
2. You reach outside the mainstream to adopt the best of any community: Open Source, Agile, Java, Ruby, etc.
3. You’re not content with the status quo. Things can always be better expressed, more elegant and simple, more mutable, higher quality, etc.
4. You know tools are great, but they only take you so far. It’s the principles and knowledge that really matter. The best tools are those that embed the knowledge and encourage the principles (e.g. Resharper.)

Promoting ALT.NET or starting some new kind of cool kids club is not the point. The point is that good software design practices and principles are very important (many would say of the utmost importance), much more important than the latest shiny new tool that is coming out. If the code you write is not well designed or well tested, that problem is not going away by moving to .NET 4.0 or Silverlight.

So if you want to learn good software patterns and practices, here’s where I would start:

• Learn how to do test-driven development. The best way is to have someone teach you how to do it because it’s hard to just read about it and pick it up (although you’re more than welcome to try!). If you don’t have someone to teach you, hopefully the next technical conference or Day of .NET or user group you go to will have a talk on how to do TDD. Go to it. I have lots of TDD links and some practice projects here.
• Learn the SOLID principles and why they’re important. You can go buy this book or just read everything on this page. Again, if you next conference/user group/etc. has a talk on SOLID (and a lot of them will), go to it.
• Read some of the “classics”, like some of the books mentioned here.
• Make sure you keep your ego in check. We should never stop learning, and should never be content with where we are now. There will always be something worth knowing that you don’t know.

Test driven development is a proven technique that will help you write well tested and well designed code, but it takes some practice.

Here are some sample projects that you can work through to get some practice, along with my completed solutions so that you can see how I did it (not that my way is the only right way, of course).

If you’re in the Columbus, OH area and you want me to come give my TDD talk (which these samples came from), send me an email and let me know and we’ll work something out.

Here are some links if you want to do some more reading:

Test Driven Development

TDD Design Starter Kit: It’s All about Assigning Responsibilities
TDD Design Starter Kit – State vs. Interaction Testing
TDD Design Starter Kit – Dependency Inversion Principle
TDD Design Starter Kit – Responsibilities, Cohesion, and Coupling
TDD Design Starter Kit – Static Methods and Singletons May Be Harmful
Succeed with TDD by designing with TDD
Unit Testing Business Logic without Tripping Over the Database
Haacked on TDD and Jeremy’s First Rule of TDD
Jeremy’s Second Law of TDD: Push, Don’t Pull
Achieve Better Results by following Jeremy’s Third Law of TDD: Test Small Before Testing Big
How much design before unit testing, and how much design knowledge before TDD?
So How do You Introduce TDD into an Organization or Team?
Pair Programming Bot
Why write unit tests?
Empirical Studies Show Test Driven Development Improves Quality
The Relative Cost of Fixing Defects

Rhino Mocks

Rhino Mocks 3.5 Wiki

StructureMap / dependency injection

Introduction to StructureMap
Jeremy Miller’s blog (author of StructureMap)
DimeCasts on StructureMap
Inversion of Control with the Plugin Pattern
What’s so great about Inversion of Control?
The Dependency Injection Pattern – What is it and why do I care?

Behavior Driven Development

Behavior Driven Development article from CODE Magazine – this one is a must read if you want to understand BDD.
BDD Wiki
Introducing BDD

Software Design

Writing Testable Code Is About Managing Complexity
Writing Testable Code

NBehave

NBehave.org
NBehave on CodePlex
NBehave source code

ReSharper

ReSharper website
ReSharper TDD Productivity Plugin

NUnit

NUnit web site