May 29, 2013

Using abstraction to understand systems

I just stumbled on a very well done interactive post by Brett Victor explaining the ladder of abstraction concept and how to put the idea to work exploring and understanding complex systems.

The most exciting engineering challenges lie on the boundary of theory and the unknown. Not so unknown that they're hopeless, but not enough theory to predict the results of our decisions. Systems at this boundary often rely on emergent behavior — high-level effects that arise indirectly from low-level interactions.

When designing at this boundary, the challenge lies not in constructing the system, but in understanding it. In the absence of theory, we must develop an intuition to guide our decisions. The design process is thus one of exploration and discovery.

Great use of interactive elements to demonstrate the concept.

May 15, 2013

Engineers or authors?

Interesting post by Kurt Leafstrand comparing software development to writing and publishing rather than engineering:

So, here's the insight I'm currently tossing around in my head: The problem is that software isn't built; it’s written. The final product is not like the Bay Bridge. It's like a novel.

Engineers are the authors. They start with an early draft (sometimes known as a prototype), an idea of the main characters (features) and the arc of the plot (use cases). They write a few chapters. They learn how the characters are acting and whether things are moving in the right direction. Then they go back and tweak the storyline a bit. They iterate.

Along that line of thinking, newspaper publishing is the original agile development method.