
Minimize Code, Maximize Data - nreece
http://database-programmer.blogspot.com/2008/05/minimize-code-maximize-data.html?
======
sciolizer
Good advice, but I don't know if I would call it a best kept secret. Maybe
I've just been reading all of the right books.

Fred Brooks: "Show me your flow charts and conceal your tables and I shall
continue to be mystified, show me your tables and I won't usually need your
flow charts; they'll be obvious."

Rob Pike: "Data dominates. If you've chosen the right data structures and
organized things well, the algorithms will almost always be self-evident. Data
structures, not algorithms, are central to programming."

Eric S. Raymond: "Fold knowledge into data, so program logic can be stupid and
robust."

Peter Norvig: "Use data-driven programming, where pattern/action pairs are
stored in a table."

~~~
silentbicycle
> Maybe I've just been reading all of the right books.

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.

------
kqr2
I think he's endorsing "data driven development", i.e. if you focus on
capturing the right data, you can simplify your application logic immensely.
In his magazine example, by encoding the magazine regulation rules as table
columns, the owner would have been able to modify the behavior himself.
Instead the rules are encapsulated in complex program logic that neither the
author or owner are willing to modify for fear of breaking.

I think DSLs (or domain specific language) would probably be too difficult for
the magazine owner. If it was database driven, he could use a gui tool such as
phpmyadmin to edit the magazine regulation rules.

~~~
jwilliams
> If it was database driven, he could use a gui tool such as phpmyadmin to
> edit the magazine regulation rules.

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.

~~~
DougBTX
Reminds me of the "The Customer-Friendly System", where all of the "data" was
taken out of the program and out into a Visio diagram.

[http://thedailywtf.com/Articles/The_Customer-
Friendly_System...](http://thedailywtf.com/Articles/The_Customer-
Friendly_System.aspx)

The thing is, "data" and "code" are the same thing, it's just a matter of
presentation. Sometimes data is easier to read if it is in if blocks,
sometimes in tables, but very rarely in Visio diagrams...

------
Hexstream
The author seems to be advocating DSLs unknowingly.

~~~
kendowns
Nope. kqr2 had it right, the approach was to move parameters into tables that
the user could edit. Asking the user to spell anything out is not in the cards
for that example.

------
MaysonL
"All programs are compilers for data."

~~~
gaius
All your compilers are programs for us!!

