In a the constant rush of new techniques in the development world it’s hard for us (and by us I mean working developers) to keep up with everything. That is the point though, you don’t have to. Not everything we learn will be ultimately useful to us. I learned “awk” in university but I’ve never used it. However, this doesn’t mean we can be complacent either! I want to learn about the latest developments or I feel like I’m losing my grip on my skills, personally I think that’s a trait of all (hmm - ed) developers. Granted, I’m sometimes a little behind the crowd (I didn’t touch .NET until 2005) but that’s neither here nor there.

There is a danger though, as I learn new techniques I immediately begin to see places in my current projects where I can use them. Developers also need restraint. If you had a snowboarding lesson, would you immediately go and enter a freestyle competition? There is a big problem with applying something you only used once in a tutorial. On the other hand if you never applied it how will you learn. This is always a big argument with management and developers in my workplace - and I can only assume other work places. When is it ok to apply your new technique while minimising the fear of introducing risk into the project?

The similarsticking point is…. *rumble of thunder, flash of lightening* refactoring. There is a beleif engrained into many schedule driven managers that refactoring will take until the end of time and will cause World War 3 if even attempted. The alternative being to just hack on top of hacks. The only way to avoid this is to just refactor when nobody is looking. It’s a faster way to fix a bug and eventually people will turn around to your way of doing things. As we all know refactoring should always be accompanied by unit testing in order to prove that the code is working the same way. I have run into a problem with this golden rule.

There never seems to be any unit tests in the first place and beginning to write these unit tests is some of the toughest work I’ve attempted in a while. It’s very difficult to get motivated to add something like unit testing to a project when management (and even senior programmers) are discouraging it. This is terrible practice. It promotes laziness and results in a project which is largely untested and is very difficult to sensibly refactor without spending a day debugging the bloody thing. I don’t necessarily mean fully test driven development for Pete’s sake, I just want to know my code is working! Is that too much to ask?! I have resolved to do everything I can to improve the processes in any project I work on. I’ve been guilty of inaction, of not saying what I think. Actions speak louder than words, and words work too. So from now on I will write tests for whatever I touch, no matter what. If there is no unit testing framework included, I will include it. I will endeavour to improve any code I touch and leave it in a better state than when I came across it. No more hacks. No more time wasted worrying that I should be doing things the right way not the fast way. In the long run it will be faster.

I’m just beginning to look at the .NET MVC framework which so far I am in love with. It’s so nice to see that good practice is finally being built into the project templates. Exposure to such shoddy practice means I can see how simple changes like this from the tool makers will make my life so much easier on maintenance. tasks two years down the line.

So thanks Microsoft, perhaps I won’t have a heart attack after all.