| Well since I've limited to 1 post a day here (very irritating!), this is it! System dynamics is the name of the field. I studied it outside a CS curriculum as a "high-level" topic, but really I took to it like a duck to water because any good coder, does this. Its the difference between a "green" coder and an "experienced" coder. And it shows up in several of the maths/fields. Anywhere there is complexity, nonlinear feedback, and long delays in feedback, you get "emergent" system behavior. I try and tell people, you can't oversimplify things, you can only stuff the complexity somewhere else. And when you adopt a framework, its a set of tradeoffs (on where it shoves the complexity). Beware, frameworks that "hide" where they shove the complexity (because it will always bite you in the ass). Sort of like poker, if you can't spot the mark (complexity);) I hate to tell you this, but most people doing hiring for coders, have NO IDEA about this level of coding. They're just looking for cogs. How many times have you heard, "the system is so complex, no single person at the company understands it?"... inevitably followed by a series out catastrophic failures that are largely, systemic hazards. Thats why there is such a large "framework adoption" movemen in CS. Not because the companies can't dev the software inhouse; but because they don't understand what they are missing. The mismatch between the "coder" and the "architect" (or worse where they've fetishized the divorce between system requirements and implementation). The whole CI is about trying to close the gap using functional testing and small code updates. But it doesn't work; you can't test for what you don't know (demand-specific instability)... So now you have to instrument the entire codebase just to make it run (or take out the particularization even further ala "containers"). More than anything, this makes the difference in the quality of the coder/codebase. If you have a good grasp of how things change, rather than static targets; you don't have to go through the entire morass. You just code it right the first time. The other thing that really matters, is domain modeling (separate from system dynamics, which is actually implementation/environment specific). Knowing your problem well, and being able to correctly pin the context boundaries, is super critical. Last is some control theory; that is, how to auto-remediate the problems as they develop. Believe it or not, you don't need large amounts of instrumentation, in order to do this. Good solutions, automatically trade-off in direct sensing of changes in algo. performance/inputs. They are "ROBUST". |