The funny thing about software projects: Even the most off the cuff ones seem to live forever. Want to tell whether a piece of software has any merits? Come back in 5 years, if it's not in use it was better never done. It's true even for seemingly single purpose scripts-- this post is prompted by a recent trip through my archives to dig up a string parser from the late '90s. That script was for the very particular purpose of matching a Taiwan Mandarin wordlist against a mainland one, but it wound up being a useful basis for some XML-ery I had to do over the weekend.

I've found that a true best practice is design as if the software would be revisited a few years in the future, for a job that was similar but ever so slightly different. In short, design for unforeseen reuse.

Some quick principles:

• externalize all data, no compiled strings ever
• hardcode nothing but the moving machinery parts, factory patterns everywhere
• make heavy use of facade patterns, make that GUI replaceable
• couple to interfaces only

Basically, design patterns are our best friend. If you missed out on that first edition Booch when it was still hot from the presses, start here: http://java.sun.com/blueprints/patterns/