What is “good” code? Some define it as “beautiful.” Some equate it with experience. Some with cleverness. Some can’t tell you what it is. Others know it when they see it. For me, “good” means maintainable.

Good code, yes, has grace and beauty. But what makes it worthwhile is that it’s easy to work with. It’s easy to add to good code. It’s easy to take away. It’s easy to make changes. It’s easy to fix bugs. And bugs are rare. Good code does what you want it to, usually the first time. Good code is a joy, not a burden.

This should be the normal state of software. How many developers live in the opposite state? They think that adding a feature always takes a long time and many lines of code. They think that getting cozy with your debugger is part of the process. They think that long hours sitting in front of the computer screen means you’re doing your job. It doesn’t. Long hours means you’re doing your job poorly.

Consider these truths of quality code. The best developers know them without thinking. To them, good code is second-nature. They’ve internalized these truths. They’ve reached nirvana. They are one with the code.

SourceSafe is one of the costs of working in most Microsoft shops, and some non-Microsoft shops as well. There’s no particularly good reason why a shop has to use SourceSafe. But many shops are simply scared to use a real source-code control system like Subversion , the current standard for most non-Microsoft development work. They’re afraid of losing their project history, afraid Subversion won’t integrate with their other development tools, afraid of not being able to use it properly or of losing features. All the reasons they give for sticking with SourceSafe really boil down to “Better the devil you know…” and “I’m too busy and too lazy to improve our technical environment.” (This is also frequently the substance behind the fear of automated builds, unit tests, and so forth.)

The best reasons to stick with SourceSafe is that you don’t want to lose your project history—but see #1 below—and that it’s tightly integrated with Microsoft’s IDE—but see #3. As I said, there’s really no good reason why you have to use SourceSafe.

Direct from the school of hard knocks, here are the top 8 reasons why software teams everywhere, even in Microsoft shops, should abandon SourceSafe:

Why do programmers hate writing unit tests? Why do they hate even more writing unit tests before coding?

Most software developers have never seriously tried test-first. Or if they tried it, they did not do so in a supportive environment where they could learn what they were doing. But more likely the former. So they come up with excuses: “We don’t have time to write unit tests.” Or: “Unit tests can’t bullet-proof your code.” They’re reacting out of fear, not out of empowerment, trying to find reasons for being miserable, rather than making their lives better. The neat thing is that occasionally you’ll find one of these developers who, when you face him with the facts, nearly trips over his own feed backpedalling. That’s fun to watch. And he does this all without ever taking back his opinion of test-first. That’s wicked philosophical.

As Kent Beck explains in Test Driven Development By Example, test-first comprises three steps:

This is a story about refactoring a legacy system.

First you have to understand something about the system we were working on. It was a legacy, enterprise web-app written mostly in C++. Numerous consultants wrote much of it back in the 20’th century. At the time, money had been tight, and the most important goal the consultants had had was getting new features delivered. So a consultant would be hired to add features as fast as he could and pad his resume at the same time. For example, one of these consultants apparently wanted to be able to say that he developed a web server. So he did. And when I worked on the system, we were still saddled with it.