Minimize Code, Maximize Data

The sad thing is, by reading books at all you're already way ahead.

The flexibility data-driven programs have is why people say that "data is code" (the flipside of Lisp's "code is data").

Also, I found working with ML (OCaml, in my case) made thinking in terms of types and overall data-structure design much clearer. It's a major strength of the language, and spending some time with it will probably give you insights usable in most other languages. ML was designed by people who knew Lisp quite well, and felt that (for some problems - in their case, theorem proving) it would be greatly improved by having a better type system.

This is great, but it's also worthwhile keeping in mind testability.

Now, your code is more robust, so that helps counter this a little - but by increasing the number of data points/variables you introduce more boundary cases. You don't want the magazine owner modifying something basic with an unexpected consequence.

I've worked recently on a lot of projects that use Business Rules Engines - similar concept - externalise your logic into tables of data/rules. End users can modify these rules to change the way the system operates.

The lesson I learned is that the causal downstream user isn't as cognizant of change control than someone who's been in the development cycle. This led to a lot of unexpected conflicts - for example, a certain threshold was lowered considerably as part of a campaign. This made 90% of submissions eligible for automatic (Straight-Through) processing as opposed to 10% before... Unfortunately the downstream systems weren't prepared for a 9x increase in the amount of load. So it fell on it's face.

Not to say this isn't a good idea - but something to keep in mind.