Subscribe / Unsubscribe Enewsletters | Login | Register

Pencil Banner

10 practices of highly ineffective software developers

Andrew Oliver | Aug. 10, 2012
Some are bad habits to overcome; some are poor decisions forced by managers who don't know what they're doing. Read 'em ... and weep

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.

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 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.

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.

 

1  2  3  Next Page 

Sign up for CIO Asia eNewsletters.