Something to Avoid While Programming

Some activities and thoughts need to be avoided while programming. Sometimes we realize our mistakes and do them anyway. I admit that in my time developing software I’ve probably done this more times than I would like to admit. I make an effort to avoid making these types mistakes, and I attempt to encourage others to avoid the same pitfalls. While working with others I certainly tell them when they’re gravely mistaken about something.

The first thing I would like to emphasize is that this mistake is fairly common everywhere in life. It is of course procrastination, and I think I’ll rip off the classic line I’ve heard a million times. Don't put off until tomorrow what you could do today. Now I need to be careful how I say this, because I could get YAGNI people jumping at me for saying this. Obviously don’t do everything today just because you can. That is silly, but things that will assist greatly in maintenance should not be put off. Since I’ve been on a bit of a testing kick lately, I might as well focus this toward testing.

I am sure a lot of you have been in the situation where you really just don’t feel like writing your test before you write your code. Ha! Who am I kidding? Most developers don’t follow TDD anyway, so most of the people reading this wouldn’t have done that anyway. A large group of developers have started writing unit tests in general even if they’re not writing them first. However, this still applies as I am sure many of those developers want to wait until a full feature is “complete” before testing.

Your code is not complete until it is tested. Keep in mind that down the road you might forget the business rule you were coding, so it is important to create the tests at the same time as you’re writing the production code. Developers will try to say, “we will write the tests when we’re done” or “we’ll refactor this later”. Do not dare believe a word of that crap. Always assume you will not have time to come back later and refactor. There is a good chance you will not have that chance. Also if you don’t fix things now they’ll just bite you later.

One way to help keep yourself on track is to work with a partner. One very powerful aspect of pair programming is that the second person will nag you and force you to get to things now. That is part of the job description for both parties while pair programming. Don’t let the other person skip out on anything. Be careful though, because that other person will be just like Wimpy saying things like, “I’ll gladly test that Tuesday to continue coding today.”

Comments