Jon Kruger

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.

• Leave a comment... (8)

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). (Note: you can also pull the code doing using SVN from here: http://tdd-starter-kit.googlecode.com/svn/trunk/).

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

• Leave a comment... (3)

Someone asked me the other day what new tool or technique they should learn, and the first thing that came to my mind was test-driven development. Test driven development is a proven technique that will help you write well tested and well designed code by writing your tests before you write your implementation code.

The best way to learn TDD is to watch someone do it. So on Thursday, July 23 from 12:00-1:00, I’ll be doing a lunch & learn presentation on TDD at the Quick Solutions office at Polaris (440 Polaris Pkwy, Suite 500 (5th floor), Westerville).

Lunch is provided (awesome!), so if you’re coming, please email amorey at quicksolutions dot com and let us know that you’ll be there.

I’ll show you the tools and techniques that I use to do test driven development and we’ll walk through the TDD process for some simple features. We’ll cover such tools and topics as NUnit, Rhino Mocks, behavior driven development with NBehave, and dependency injection, and I’ll give you the base code that I use on all projects to help write unit tests so that you can hit the ground running.

Can’t make it? I can come out to your place of work if you’re in the Columbus area and give this presentation again. If you’re interested, send me an email and we’ll set something up.

• Leave a comment... (1)

We’ve all worked with people who are adverse to change. Getting people to change and helping them to change is very difficult. The challenge is to convincing people of the need to change without tearing them down.

People always have a reason for doing things the way that they do them. I personally love ASP.NET MVC and I think that it makes software development much easier and must faster. Other people are scared of MVC because they are very comfortable with WebForms. I write tests all the time, but other people have no desire to write tests. But we all have a reason (whether good or bad) that we do things the way that we do them. The challenge is finding a way to give people a reason to change.

The fact of the matter is that many people are adverse to change. This could be for several reasons.

1. They don’t know change is an option. Every year I look back at how I wrote software a year ago and there is always something that I can’t believe that I did a year ago. A year ago I thought I was a good developer. Was I a good developer a year ago? I think I was, but there is always something that you aren’t aware of that can help you. Everyone is at different stages, and not everyone is at the same place as you. This does not necessarily mean that they are stupid or ignorant or that they don’t care, maybe they just haven’t come across something yet.

2. They don’t know why they should choose change. If you’ve been doing WebForms for the last 5 years, you probably feel that you’re pretty good at it. So why should you adopt ASP.NET MVC? I mean, is ASP.NET MVC really beneficial or just another technology that you have to learn? That is a completely legitimate question to ask, and many people are asking it these days.

If you’re trying to get someone to adopt ASP.NET MVC (or any other technology that is new to someone), you need to become a salesman. You need to sell that person on why said technology or way of doing things is going to help them. “This is the right way to do it” is not going to work. That doesn’t tell them how it’s going to help them. You need to convince them that the new way will make their life easier and then show them how to do it.

3. They don’t know how to go about changing. The best example of this is teaching people how to write unit tests. First you have to write your code so that it is testable, which means that you need to understand dependency injection and some DI container like StructureMap. Then you have to learn how to use a mocking framework like Rhino Mocks. You have to learn the difference between a unit test and an integration test, and ideally you will also learn how to write tests first. Yikes, that’s a lot of stuff to learn! The only way that I learned it all was by working with other people that knew how to do it and taught me how. So your colleagues may be willing to change, but they might just need some guidance (or a lot of guidance). They also have deadlines and don’t want to risk being late because they were trying to learn something new. This is where you need to convince them that writing tests will same them time and make their life easier because they will write less bugs and it will be easier to make changes to their code.

4. They don’t want to change. Many people are adverse to change and that’s just their personality. Other people are stubborn and don’t like people telling them that they’re wrong. These people are the difficult ones to deal with. Sometimes all of your efforts with these kinds of people will not succeed, but at least you can make an effort. I think it goes back to showing people why they should change — that there is another way to do things that will make their lives better. But getting them to this point will take a lot of patience and encouragement along the way.

Most people don’t change overnight. Even if someone wants to adopt all kinds of new technologies and practices, it may take them a long time. So give them something small to change. Instead of trying to totally rewrite their entire codebase, show them how to take a feature and write tests for it. Show them how their tests give them peace of mind because they know their code is working. Now hopefully you’ve won some more trust and can move on to bigger problems.

If you’re one of the people who is nervous about change, realize that in this industry things are constantly changing. No one can keep up with it all and know everything, so we need to rely on the expertise of others and learn whatever we can from whomever we can. It may require checking your ego at the door and realizing that you may not know the best way of doing something.

Changing might be hard work. It’s much more comfortable to do something that you know well. But nothing worthwhile is ever achieved without hard work. I promise you, you will be much better off in the end and you’ll be glad that you changed.

• Leave a comment... (4)