Writing great software is not that hard. But software developers can be their own worst enemy in trying to code the good stuff because they lapse into sloppy or wrongheaded practices.
Actually, scratch that: The developer's worst enemy is really the eager technical manager who tries to deliver a project faster than possible and pushes developers to engage into ill-advised practices. In high-end enterprise and Web-scale projects in particular, that can result in wholesale disaster.
[ Go beyond the smartphone and find out the emerging platforms developers should target next in the InfoWorld slideshow. | Learn how to work smarter, not harder with InfoWorld's roundup of all the tips and trends programmers need to know in the Developers' Survival Guide. Download the PDF today! | Keep up with the latest developer news with InfoWorld's Developer World newsletter. ]
These pitfalls are well known. Few developers would argue with them -- or at least with most of them. Those who dare to disagree may do so in the comments section at the end of this article.
1. Go even a day without writing a unit test
Developers love to get mired in details like the difference between a unit test and a functional test. The answer: Who cares? What matters is that you have good coverage and can tell when something breaks. It matters that you have a good starting point to run code and set a breakpoint in the debugger. The only way this can work is "as you go."
Tests are also good expressions of your requirements. Despite a mountain of evidence, I still occasionally hear: "You need to prove to management that unit tests are worth the time."
These managers are the tech industry's equivalent of climate change deniers. No amount of evidence will ever meet their burden of proof. They're doomed to deliver very late, buggy projects that fail to meet user expectations.
2. Go even a day without a build
With tools like Jenkins CI, there is no excuse. It takes only a few hours and a VM to set up an instance of Jenkins suitable for most projects. It can even be configured to run when code is checked in to a revision control system such as SVN or Git. The unit tests can run, metrics can be gathered, and emails can be sent when something breaks. Your repeated build is the heartbeat of a healthy project. You can't live without a heartbeat.
3. Use ClearCase (or any slow or pessimistic locking revision control system)
ClearCase is slow -- period. And ClearCase isn't the only horribly slow revision control system. Anything that causes developers to "wait" to check out or check in their code is a massive drain on developer productivity. It also causes aggregated risk. Even with a repeated build, if developers wait until they have time to check in, the build is nearly useless.
Worse, this means a given machine may have the only copy of a developer's work for a longer period of time. Over a lengthy enough timeline, the survival rate for any piece of hardware approaches zero.
A pessimistic locking revision control system isn't just a disaster in the sense of "oops, forgot to check in and went on vacation." It's a continual drain on the project. I find it incredible that there are still people who believe it's useful to have half the team waiting for a file to unlock than potentially having two people working on the same file (and probably different parts that will merge automatically anyhow).
4. Deliver to production without a branch
A vast number of organizations have not yet figured out how to create a branch. Branching is the magic bullet that allows you to deliver a release, fix bugs in that release, but not release any half-developed new code to production. Branching is not actually difficult. There are several effective strategies for it. In fact, every revision control system I've encountered in the past few years supports it. However, branching requires that developers familiarize themselves with their revision control system.