August 09, 2012, 1:28 PM — 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 testDevelopers 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 buildWith 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.