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 defaultA 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.
Sign up for CIO Asia eNewsletters.