Last week, my friend Furqan and I had an insight: Many software developers build fragile systems, because they tend to focus on technical components rather than the functional interfaces between those technical components. For example, a developer may devote much of his/her time on the code for the billing adapater implementation, without spending adequate time to define/re-factor a robust billing interface.

Off the cuff, I sketched a simple whiteboard diagram: Two small boxes inside of a larger box.

My theory is that most people will gravitate towards seeing the two small boxes; in other words, they focus on the “figure” (in the artistic sense of “figure vs. ground”) However, the proper focus should be on the empty space (the “ground”) between the small boxes and the larger box. As humans, we’ve evolved to focus on concrete visual images which make up the “figure.” As long-term system-builders, we need to fight this “concrete thinking bias” and instead focus our minds-eye on the “ground” instead.

Agile software development requires continuous software refactoring. Functional interface design facilitates refactoring and help build robust systems. Unfortunately, clean functional interface design is often neglected in order to “just get the code working.” Treated as a luxury, it is eagerly sacrified at the altar of expediency.

Imagine my smug self-satisfaction — how fun to criticize others for the fundamental flaw in their conceptual thinking!

Funny how life finds a way to hold up a mirror to your face:

This morning, I reviewed the current high-level architectural diagram for Kinetic. I’m embarassed to admit that it also focuses too heavily on components, and not interfaces. The Parser/Interpreter reads data from an Intermediate Data Model. The Diagram Generator generates a PDF. Very concrete component definitions. Very fuzzy interface definitions. In a nutshell, poor design. It lacks the rigor of deliberate functional thinking.

Please excuse me while I wipe the egg off my face, thanks.