10 Worst Habits of Software Developers

1. Code directly to the RDBMS by default

There has always been a large amount of nonsense written about Object-relational mapping systems. In general one or two edge cases are used to justify dumping the ORM and writing "directly" to JDBC or OleDB. The truth is you can't afford to debug the irrelevant CRUD code. Almost every ORM system allows you a way to handle those one or two edge cases directly without full abandonment.

2. Write your own cache, database, thread pool, connection pool, transaction manager...

Unless you work for a company or an open source project, there's almost nil reason to write a code for these, even if you are aware of what you are doing. Don't code what you don't need to code when reliable solutions that work have been QA'd by a large number of people. At least 99 percent of the time, that justification will overshadow your reasons for "writing a better one."

3. Try to buy your way out of software development

It is a fact that commercial apps make more sense than internal app dev in some cases. But it's also possible to license, say, the entire Oracle or WebSphere stack and deliver absolutely nothing. There's a limit to how much stuff your development team can actually absorb and use before the complexity of the stack outweighs any supposed technical benefits.

4. Wait until the end to engage users

In marketing, someone has to validate that the product development group has hit the mark and someone is going to buy it. It is the same way in software. Although, it can be embarrassing and troublesome to show your software in a "rough state”, someone needs to make sure the end product will pass muster with users as early as possible.

5. Develop without capacity/performance requirements

At least a vague estimate of how many users will use a software isn't just good practice but is basic business forecasting.To develop a reasonable load test, you need performance expectations. You need to know how many users the system should be expected to handle.

6. Wait until the end to load-test

Some of the most effective organizations who've implemented test-first and pair programming still think load testing is something to do at the end of the project. But it should be noted that if you are making decisions that will keep your project to meet performance or scalability requirements. The best time to catch those decisions is early in the project because some issues can bring a huge amount of rewriting if caught too late.

7. Deliver to production without a branch

Branching is the wonderful bullet that allows you to deliver a release, fix bugs in that release, but not release any half-developed new code to production. But still a vast number of organizations have not yet figured out how to create a branch which is actually very easy. There are several effective strategies for it and almost every revision control system supports it.

8. Use ClearCase (or any slow or pessimistic locking revision control system)

ClearCase and many other revision control system are very slow that causes developers to "wait" to check out or check in their code. This drains a developer’s productivity massively. It also causes aggregated risk. Even a repeated build is useless if developers have to wait to check in. It's a continual drain on the project.

9. Go even a day without a build

A repeated build is the heartbeat of a healthy project and a developer can't live without it.

With tools like Jenkins CI, there is absolutely no excuse. It takes only a few hours and a Virtual Machine to set up an instance. It can even be configured to run when code is checked in to a revision control system such as SVN or Git. It allows unit tests to run, metrics to be gathered, and emails to be sent when something breaks.

10. Go even a day without writing a unit test

Developers spend a lot of time in details like the difference between a unit test and a functional test. In fact, what matters actually is to have good coverage and tell when a code breaks. Also you should have a good starting point to run code and set a breakpoint in the debugger. They should concentrate on this rather as tests are good expressions of your requirements.