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!

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.

If there’s one thing that everyone in software development can agree on, it’s that everyone has an opinion on what the best way is to do things. We have lots of books, blogs and articles touting “best practices” and telling us how to do things (and how not to do things).

Often times as a consultant, you are brought into an IT shop where the native developers aren’t using the latest and greatest technology and might not be using the so-called “best practices” that you subscribe to. Usually in these situations, the people that brought you in are bringing you in for your expertise and are expecting you to do things the right way. This can lead to the native developers feeling somewhat threatened.

Recently a friend of mine started at a new client and noticed that the developers there were do most of their data access through dynamic SQL written in their C# code. When he questioned why they did it that way, the developers got defensive, saying things like, “We’ve been doing it that way for years and it’s been working for us.”

While the “best practices” would not recommend you doing all of your data access this way, it dawned on me, this guy is exactly right. He’s been writing his dynamic SQL for years, and he’s been succeeding in delivering working software. So in his mind, he’s not doing anything wrong.

There are two ways of handling this situation. The one that many people choose it to rip on the guy for being so stupid for ever thinking of doing it that way, while saying things like, “No one does it that way anymore”. All this does is alienate the developer and turn them off from trying to learn something new.

The preferred method is to show them that there is a better way. I once asked Andy Hunt how to get people who don’t write unit tests to start writing unit tests. His answer was that I needed to show them what was in it for them. I don’t think he could’ve been more correct. No one wants to do something just because it’s a “best practice” or some smart person said you should do it that way. We’ve all worked with people or seen projects where some “smart” person made something way more complicated than it needed to be and no one else could understand what they did or how to write code using their framework. No one cares if those people used “best practices”, you just hate having to come to work and deal with the mess that they made.

So if you’re working with someone and you think that there is a better way than how they’re doing something, show them the better way. Acknowledge the fact that what they are doing is working for them (they probably wouldn’t be doing it if it wasn’t). Just don’t belittle them for doing it that way, because they may be doing the best that they can.

Every year, thousands of software development projects are developed. In most of these applications (especially line-of-business applications) you will see a lot of the same UI patterns:

• When the value in one dropdown changes, the list in another dropdown needs to change
• Two list boxes with arrow buttons that allow you move items between the lists
• A grid with add/edit/delete buttons that allow you to manipulate the list

Most applications have other common characteristics, like:

• The concept of a User that has to log in, reset their password, and change their password
• Some concept of security roles
• Loading objects from a database by ID

Every project also has housekeeping tasks, like:

• Setting up automated builds
• Copying files to a QA site after a build
• Coming up with a way to create a development copy of the database

The problem is that on every project, it seems that way too much time is spent getting this stuff to work. Why??

These are solved problems. We’ve all solved them before. But we end up re-implementing the same stuff over and over.

This is a problem. Making an AJAX call to update the list in a child dropdown when the parent dropdown changes is not rocket science. I don’t want to write this code ever again. I want to write stuff like this:

State: <%= this.Select(model => model.State)
                      .Options(Model.StateOptions, opt => opt.Id, opt => opt.StateCode)
                      .UpdateOptionsFor(model => model.County)
                      .WithAjaxCallTo(“/state/GetCountiesInState”) %>
County: <%= this.Select(model => model.County) %>

(I’m using the MvcContrib HTML Helpers here.)

You write the code to implement this fluent interface once, and you don’t ever have to write it again. That’s the way that it should be. Every time you do something, you should be trying to find a better way to do it so that you can do it better next time.

A lot of people have already done lots of work for you, and you should take advantage of it. I’m talking about things like this:

• Using the built-in ASP.NET Membership stuff instead of rolling your own code to do Forms Authentication
• Using Rails scaffolding to create your website
• Using styling and controls from jQuery UI
• Using convention-based MVC frameworks (e.g. Rails or ASP.NET MVC + MVCContrib)
• Using the auto-mapping capabilities of Fluent NHibernate instead of writing mapping files or CRUD stored procedures
• Use S#arp Architecture as the framework for your application

Every developer should have a toolbox of code that he/she can draw from so that you can avoid being a plumber and spend your time doing valuable things, like writing business logic, designing user interfaces, and other things that you are being paid to do.

I’ll be speaking at the Central Ohio .NET Developers Group this Thursday, Feb. 26 at 6pm… I’ll be talking about Unit Testing JavaScript using Test Driven Development.  We’ll go through what TDD is and how it can help you and show you how to write JavaScript tests against a sample application using QUnit.  Hope to see you there! (Oh, and there’s free pizza too!)

CONDG meets at the Microsoft building at Polaris… the address is 8800 Lyra Dr., Columbus, OH 43240.

One of the common complaints that I’ve been hearing about our industry is that our industry lacks quality in general.  The evidence of this is this never ending cycle of rewriting software over and over because it is unmaintainable, buggy, etc.  Many people would say that this is sometimes a result of developers throwing code together quickly without taking the time to think out their design, write unit tests, or manually test their code. 

Thankfully the pendulum seems to be swinging and people are starting to expect higher quality from themselves and from the people that they work with.  More and more people are jumping on the TDD bandwagon (at least the people I work with are). 

However, speed is still very important — that is, the amount of time that it takes a developer to complete a task or the amount of time that it takes for a team to complete a project.  The fact of the matter is that we all have deadlines for our projects (well, maybe not if you’re working on open source projects).  Hopefully those deadlines are realistic, but they are deadlines that we have to meet.  So quality is definitely important, but speed cannot be ignored.

It seems to me that there is a stigma against developers who say that they work fast.  It seems that if you walk into an interview for a developer position and you say something like, “I’m capable of getting a lot of work done in a short amount of time,” you might as well keep looking because the interviewer will often times assume that you write crappy code and don’t care about quality.

But what if you are able to work quickly and not compromise on quality?  That would be the best of both worlds!  Just like we should all strive to write better quality software, we should also strive to get it done in as quickly as possible (without compromising on quality, of course).  Here are some ways that you can do this:

Become a keyboard ninja

They put those keyboard shortcuts in Visual Studio for a reason, you know.  If you’re writing .NET code you’re probably spending most of your day using Visual Studio (or another IDE if you’re using another language).  So why wouldn’t you take time to learn the keyboard shortcuts?  If you are using ReSharper (and you all should be), there are even more keyboard shortcuts to help you.

When I got my first job, I worked some guys whose goal was to never use the mouse.  These guys knew the keyboard shortcuts for everything, and they sure could get around fast.  Watch somebody who uses the mouse a lot, and watch how long it takes to stop typing, grab the mouse, drag and click, and go back to the keyboard.  It totally takes you out of your rhythm.

If you want to learn to use the mouse less, it really isn’t that hard.  Go print out the keyboard shortcuts for Visual Studio or ReSharper and tape them up at your desk.  Then anytime you reach for the mouse to do something in a menu or a toolbar, look on your cheat sheet and find the keyboard shortcut.  Highlight it on your sheet so that it’s easy to find next time.  You’ll be a keyboard ninja in no time.

Create easy-to-use frameworks

I’ve been on projects where it was really difficult to do simple tasks because the application’s framework put so much burden on the developer because it was way too over-complicated.  Sometimes things have to be complicated, but many times they don’t have to be.  When I’m designing frameworks, I will spend more time on writing framework code if it will make life easier for the developer using it.  Frameworks should help developers get things done, not hinder them.  The success of your project may hinge on this.

Use code generation tools

If you find that you’re doing a repetitive task over and over again, take the time to set up some code generation templates to help you generate that code.  There are many ways to do this:

• Code generation tools like MyGeneration
• Visual Studio code snippets
• ReSharper Live Templates (code snippets on steroids)
• Visual Studio file templates

Don’t get stuck writing plumbing code over and over again.  Usually there is some repeatable pattern that you can recreate using a some kind of code generation tools.  Every developer should be at least somewhat familiar with these kinds of things.

Control distractions

There are lots of things that can distract you while you’re writing code, like meetings, emails, IM, Twitter, etc.  Sometimes you can’t always control these (e.g. meetings) but the rest are under your control.  The world is not going to end if you can’t check your email, send IMs, follow Twitter, etc. for a day.  I’m not saying that you should always shut those off.  I’m just saying that we all need to be careful that they don’t become a distraction.  It’s really easy to get caught up in discussions on Twitter, but remember, you’re being paid to produce, not discuss things on Twitter.  (If you are getting paid to participate in discussions on Twitter, then lucky you!)

Buy ReSharper

I think I’ve already mentioned ReSharper several times now.  It’s only $199 for a personal license.  I don’t know how I wrote code for so long without it.  My company bought a license for everyone on my team and it was the best money they ever spent.  Some of the refactoring tools and keyboard shortcuts are really useful if you’re doing TDD and creating a lot of interfaces.

Recently I lost several team members from my team. As a result, suddenly there is all this top-of-the-line hardware lying around. Of course, I can’t let good hardware sit there and rot! So now I have the developer’s dream environment.

You are looking at my quad-core, 64-bit, dual-boot system with 4 20″ flat panels and 8 GB of RAM. Synergy let’s me use one mouse and one keyboard to control both machines. Now that’s hot!!

Most of us have lots of pictures, music, and other stuff on our home computers that we can’t afford to lose.

We’ve all heard many times that we need to back our stuff up, and other people have posted about this before. Unfortunately I ignored all the warnings and was met with a “disk read error” when I booted up my laptop last week. Crap.

Luckily I had been backing up a lot of stuff to CDs, but I had slacked off over the last year. Most of the pictures that I really wanted I could get back from other people, so I didn’t lose too much.

(Side note: seeing “disk read error” has an upside — the wife turns to me and says, “I think we need to buy a new computer.” The Wife Acceptance Factor will never get any higher than that.)

My Backup Strategy

I need something that is automated so that it doesn’t rely on me having to manually go and burn CDs, upload files, etc. because I will forget to do it. I need something that happens frequently because with a newborn in the house I will be taking lots of pictures, and I can’t afford to lose them. I didn’t want to back up to another computer in my house either (because I don’t want to maintain it, and to protect against some unlikely event like a house fire or someone breaking in and stealing everything). Here’s how it all works:

I downloaded and installed WinSCP, which is an FTP client that has a very powerful scripting language and has built-in functions to help you synchronize data. I downloaded the 4.1.3 beta because I needed some of the scripting capabilities that they added in the later releases.

Now that I have WinSCP installed, I had to write my script. Luckily the WinSCP scripting language has some pretty good documentation. I have two files, a batch file that I will run and a WinSCP script file that is called from the batch file. I am going to synchronize files from my machine to my web hosting provider (which I have to host my blog), which is running on Linux.

Here are the two files (I have them in my C:\autobackup directory):

winscp backup batch file.bat:

@echo off
:waitloop
echo Waiting for wireless....
Ping jonkruger.com -n 2 |find /i "Request timed out" > nul
if %errorlevel% ==0 goto waitloop
:connected

echo connected to wireless
"C:\program files\winscp\winscp.com" /console /script="c:\autobackup\winscp backup script.txt" /log="C:\autobackup\backup detailed log.txt" > "C:\autobackup\backup log.txt"
echo done


winscp backup script.txt:

# Automatically answer all prompts negatively not to stall
# the script on errors
option batch on

# Close and exit
close
exit


Note that in winscp backup batch file.bat, the stuff at the top of the file is checking to make sure that I’ve connected to my wireless network before I try and connect to the server.

You can read more about the options for the WinSCP “synchronize” script command here. Basically what I’m doing is synchronizing the remote FTP server to have the same files that I have on my local machine. I’m only doing the synchronization one way (meaning that changes on the remote FTP server will not be synched back to my local machine), but WinSCP will allow you do the two-way synchronization if you want to.

Now I set up a scheduled task in Windows to run my “winscp backup batch file.bat” file. I checked the box that says “Wake the computer to run this task”.

Just like that, all of my pictures are backed up every night to a remote server, without any interaction from me, and I can see the results in a log file. I can easily update my script file to back up other directories too.

There are probably lots of other backup solutions out there, including Mozy.com, which allows you to back up 2 GB worth of data for free, or unlimited data for $4.95 a month. Web sites like this are probably worth looking into… I created my own solution because I already had the web hosting space available and WinSCP made it pretty easy.

So now that I’ve done all the work for you, you have no excuse! Don’t wait to back up your stuff or you might end up with nothing left to back up!

Recently on our project we’ve been diving into Windows Workflow Foundation, particularly the rules engine. This process is relatively painless since Microsoft was kind enough to expose the RuleSetDialog class so that you can use the WF Rule Set editor in your application. This code is as easy as doing something like this:

// Create a RuleSet that works with Orders (just another .net Object)
RuleSetDialog ruleSetDialog = new RuleSetDialog(typeof(Order), null, null);

// Show the RuleSet Editor
ruleSetDialog.ShowDialog();

// Get the RuleSet after editing
RuleSet ruleSet = ruleSetDialog.RuleSet;

That’s how simple it is to include the RuleSetDialog in your application. The problem is that the Intellisense dropdowns in the RuleSetDialog expose private and protected members of your class, and Microsoft doesn’t give you any way to filter the Intellisense list. So you end up with stuff like this:

Microsoft is aware of this issue, and they haven’t said anything definite about doing anything about this problem.

When you’re writing a commercial application or something that non-developers are going to use, you don’t want this kind of cryptic stuff in the list. I don’t want to expose all of the private members of my classes to the user, just like how you don’t expose private members of a class in a public API.

One way to filter the list is to create an interface and pass the interface type in as the first parameter in the RuleSetDialog constructor. This way you won’t have all of the private and protected members of the class in the Intellisense because an interface only exposes public methods. So now you’re constructor looks like this:

// Create a RuleSet that works with Orders (just another .net Object)
RuleSetDialog ruleSetDialog = new RuleSetDialog(typeof(IOrder), null, null);

This is a decent solution, but it still has problems:

• You have to create the interface.
• System.Object members like Finalize(), GetHashCode(), and Equals() are still exposed.

Like I said before, in my commercial application, I don’t want users to have to see all of this extra stuff. I only want to show them the things that I want to show them.

Well, thanks to Reflector, I was able to come up with a way to let you filter the list. In my example, I can filter out all of the protected and private members, filter out static types, only display members decorated with an attribute, or completely override the list to only display strings that I’ve added. So now you can easily get something that looks more like this:

Much better!

Now I must warn you. This solution is making extensive use of reflection to get at private and internal methods and events that Microsoft didn’t feel like exposing to us. So I felt a little dirty while I was writing it, but it gets the job done!

Here is the code. Please leave a comment if you find anything wrong with it.

Here are some other good posts about the WF Rules Engine:

Execute Windows Workflow Rules without Workflow
Introduction to the Windows Workflow Foundation Rules Engine
External Ruleset Demo

Enjoy!

I went to CodeMash this year. Last year I did not. Sure, I knew that there would be a lot of good talks, but can’t I earn the same information by reading books and blogs, listening to podcasts, etc.?

Now I see why I was wrong. People I work with talk about the value of being involved in the .NET community, and now I see why they are right.

Sure, the talks were great. But by far the best part is being able to sit down with people who know way more than me and ask them about problems that I’m having right now on my current project. That kind of free advice is invaluable.

In the technology world, there is always tons of new stuff out there, and there’s no way that I can keep up with it all (especially with a wife and a kid on the way). If I want to be someone who can make good architectural decisions, how can I do that without having knowledge of what’s out there? Since I can’t keep up with it all, I could use some other people that can help out.

So I plan on trying to be more involved in the local .NET community (user groups, blogging, etc.), and I’m really excited about it. Hopefully I can make some worthwhile contributions of my own while I’m at it.