Things I Can't Say

In the middle of projects, I sometimes find myself in despair over the quality of the code that surrounds me. Obviously, the right response is not to have a whinge, so I don’t always ennunciate my frustrations.

Right now, though, I’m working on a project with just one other developer – a developer who thinks before he codes, and understands the implications of the code he writes. Everything is just peachy, so it’s a good time to share some of the things I’ve wanted to say previously, but couldn’t…

• Just because you found it in a pattern book, doesn’t mean that it is good, or appropriate. I’ve yet to see a proper use of the Visitor pattern that wasn’t coded by an evil genius, the majority of Singleton implementations are broken, and the Factory has been irredeemably overused. All things considered, it’s better to come up with your own design, recognise the patterns within it, and only then consult your favourite pattern reference.

• Just because it is a standard, doesn’t mean that it is good. Shucks, even Sun have turned their back on EJB1.0 and 2.0.

• JNDI is not always better than a properties file. And even if it was, from where do you get the address of the LDAP server? A properties file, no?

• If changing a configuration parameter would likely necessitate a change in the code, then that parameter should be compiled into the code. It should not be in a properties file. Duh.

• Good API design is like good UI design. Most programmers think they’re great at both, and they’re wrong twice over. The “I“s in API and UI stands for “Interface” – not “Internals” – so don’t expose your users to the internals. Understand what your users need to do with your component and give them an interface that lets them do that with as little fuss as possible.

• RDBMSs are not to be treated as a directory of flat files. In particular, selecting a large portion of a database table and throwing away what you don’t want is stupid. Use SQL WHERE and ORDER BY clauses.

• Not every application needs a database. Flat files can be as ‘secure’ and and as ‘fast’ as an RDBMS.

• I cannot think of a single system where the additional deployment and architectural complexity of EJBs is paid back by a reduction in coding time, additional integration friendliness or an increase in performance. Not to say that such a system does not exist, just that it must be rare. Oh, and transparent distribution only works when performance is not an issue.

• Sometimes cutting and pasting is good. Throw-away code does not need to be an elegant masterpiece.

• In most situations though, elegance is good. Elegant code is code that can be both understood and modified with a minimum of effort. DRY is a good heuristic, if not taken to extremes.

• Bad code without bugs beats good code with bugs.

• Shipping code with bugs beats non-shipping code without bugs.

• Write code for clarity rather than speed. Please. More problems are caused by complicated code and than “inefficient” code.

• Choose a design that fits the budget. Better a sub-optimal design that is fully implemented and tested than a beautiful design that is incompletely tested and not properly debugged.

That is all. Thankyou for listening.