Bioengineering has begun a kind of revolution. DNA sequencing and synthesis has developed to the point where researches can build short strands of specifically designed DNA with very low error rates. The ability to utilize abstraction hierarchies can now be used to fabricate biological systems in a manner akin to early electronic systems engineering. There are two points to make here: 1) this is not a real revolution because this is just applying standard linear techniques to biosystems and is not rethinking anything; biofab does not harness the power of biology to the degree that evolving systems will (whenever Ken gets around to it). 2) Insofar as abstraction hierarchy fabrication will allow engineers to specialize on system design and hence more quickly invent and mass produce useful devices it constitutes a major leap in the applicability of the technology. Realizing the benefits of (2) I see no reason why we shouldn't implement the same technique for agent-based models.

The abstraction hierarchy goes (from top to bottom): system -> device -> part -> basic component. For biological engineering the basic building block is DNA; for electronic engineering it's …; and for computer models it's code. Code is built into methods which perform specific functions with well-defined inputs and outputs. Methods are combined into classes that can contingently activate specific methods and interact with other classes. Systems are built out of collections of classes to solve particular problems or reveal insights about the mechanisms employed. So for those of us already familiar with encapsulated object-oriented programming (C++, JAVA, Python, etc.) we can see how all the abstraction hierarchy has already been laid out.

Modeling toolkits like RePast and Ascape are nothing more than sets of classes (and hence all their methods) that can be used by modelers to reduce the amount of code they need to write. Many commonly-used classes are included in these toolkits (and with JAVA itself), but not all the one's you'll want are included (and some included ones are garbage). One major obstacle for new ABMers is a lack of familiarity with the full manifold of available methods and hence they spend time writing code instead of thinking about the system. Realizing the inherently modular nature of building ABMs means allowing people to specialize on one layer in the abstraction hierarchy. Let code monkeys write code and let modelers build models.

Now computer modelers are ahead of bioengineers with respect to establishing libraries of building blocks at different levels from witch to construct systems. However we are still building entire systems almost completely from scratch. My idea is that there needs to be a pseudo-revolution in computer modeling parallel to the one in biofab…ABMfab. This can be facilitated by higher-order software programs with intuitive GUIs which allow users to connect classes and their methods. My LEGO Mindstorms programming software is something like this. The ability of this procedure to create rich and useful models and quickly expend the user-base of agent-based models should be fantastic.

I admit that ABMfab might be a bit premature, but some of us should be moving in this direction. Naysayers will claim that control over the method details is a necessary aspect of modeling. That will remain true for scientists who are advancing the field, just as some scientists still need to build sensors, chips, and computers from scratch. But if ABMs have the potential to be general, non-linear system intuition pumps and problem solvers then it is precisely this engineering approach that will unlock this power. ABMfab is not intended to be a way to better understand complex systems; it is a way to make better use of them in ways that we already understand. Hopefully, even probably, the increase in use and familiarity will eventually blossom into better understanding.