5. Wait until the end to load-test
Even some of the most effective organizations I've seen who've embraced test-first, pair programming, and all of that still think load testing is something to do at the end of the project.
Justification is provided in the axiom "early optimization is the root of all evil." There is some truth to that -- for a microcosm. But you need to know if you are making fundamental decisions that will not allow your project to meet your performance or scalability requirements. The cheapest time to catch those decisions is early in the project.
We're not talking iterators vs. loops or monads. We're talking the wrong data store, wrong algorithm, wrong rules engine, and horrible concurrency issues. Those issues can incur a huge amount of rewriting if caught too late.
6. Develop without capacity/performance requirements
The first question I ask when helping people with performance or scalability problems: How many users does the business expect? Regardless of the technical roots of the problem, the shrug I often get in response to this question is the real cause. A successful project has at least a vague estimate.
This isn't just good software; this 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.
7. Wait until the end to engage users
Marketing professionals have used focus groups for decades. Someone has to validate that the product development group has hit the mark and someone is going to buy it. The same goes for software development. Whether it is an internal or an external customer, someone needs to make sure the end product will pass muster with users as early as possible.
It can be embarrassing and troublesome to show your software in a "rough state," but if you don't, whether or not you meet user expectations will be left to chance.
8. Try to buy your way out of software development
The buy-vs.-build question is one of the most basic conundrums in IT. Obviously, commercial apps make more sense than internal app dev in some cases, as do commercial or open source programs that maybe woven into some larger project. 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.
9. Write your own cache, database, thread pool, connection pool, transaction manager ...
Unless you work for a company or an open source project dedicated to developing one of these, there's almost never a reason to write one, even if you "know what you are doing." Don't code what you don't need to code when reliable solutions that work have been QA'd by the multitudes. At least 99 percent of the time, that validation will outweigh your reasons for "writing a better one."
10. Code directly to the RDBMS by default
A considerable amount of nonsense is being written about Object-Relational-Mapping systems these days. Actually, there's always been a considerable amount of nonsense written about Object-relational mapping systems. Typically one or two edge cases are used to justify abandoning the ORM and writing "directly" to JDBC or OleDB or whatever. The truth is you can't afford to debug the extraneous CRUD code. Every ORM system I've ever used allows you a way to handle those one or two edge cases directly without full abandonment.
This article, "10 practices of highly ineffective software developers," was originally published at InfoWorld.com. Follow the latest developments in business technology news and get a digest of the key stories each day in the InfoWorld Daily newsletter. For the latest business technology news, follow InfoWorld on Twitter.