One of the more profound insights from Stephen Wolfram’s “A New Kind of Science” is that small rules can lead to extraordinary complexity. Wolfram famously giv

One of the more profound insights from Stephen Wolfram’s “A New Kind of Science” is that small rules can lead to extraordinary complexity. Wolfram famously gives Rule 30 as an example, where you cannot know what each line of squares will look like before you do the computation, but he goes on to cover many other phenomena, like prime numbers and tag systems.[1] One conclusion is that complexity stemming from simple rules is relatively common in our Universe and that historically, humans have done a good job of solving the narrow pool of problems where you can know the end solution with a simple calculation (say predicting the location of a ball as you toss it up in the air). The implication is that there’s a whole “universe” of problems where we cannot know the end solution until we’ve done the work necessary to compute it. And in that sense, it wouldn’t be surprising if software engineering was a bit like Rule 30: an endless array of patterns we can’t predict until we’ve actually created the code or computed what it can do. It’s not so much that we’re bad at software engineering. It’s just that emergent complexity is part of our reality (assuming Stephen Wolfram’s insights apply to software engineering. Maybe they don’t. But it sure feels like it). I think the ancients knew this well. The Tower of Babel story is pretty old. Details the problems humans run into when they try to scale and work with many different elements: Something nobody could predict and possibly, catastrophe. [1]http://mathworld.wolfram.com/TagSystem.html http://mathworld.wolfram.com/TagSystem.html