3 ms·

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 maga

by kqr2 18y ago

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 18y ago
> 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 18y ago
  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.aspx http://thedailywtf.com/Articles/The_Customer-Friendly_System... 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...

by kqr2 18y ago

jwilliams 18y ago

> 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 18y ago
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.aspx http://thedailywtf.com/Articles/The_Customer-Friendly_System... 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...