I became fascinated with the idea of software as a material many years ago, reading Donald Schön's work on the reflective professional. Mapping his ideas on the practice of software development, and leveraging Phillip G. Armour's view of software as executable knowledge, I came up with the simple notion that we're shaping knowledge as we program (or model), that our material may react in unexpected ways, and that we should listen to the backtalk to adjust its shape. In the end, I published some of my thoughts on IEEE Software (Listen to your tools and materials, September/October 2006), with little fanfare.
Meanwhile, I was reading the early works of Christopher Alexander, like Notes on the Synthesys of Form, which predates his work on Patterns. The idea of shape (form) as a reaction to (and at the same time as a mirror of) external forces began to settle in. I wrote a few posts where the notion of decision struggled to emerge (On the concept of Form (1), Architecture as Tradition in the Unselfconscious Process, On the concept of Form (2), On the concept of Form (3): the Force Field). In hindsight, I can see how viscosity, a term I reused from Alexander's work, could be better modeled as friction in the decision space. Back then, I had no idea :-).
Giving shape to software requires that we keep some portions together, others apart. There is an intrinsic fractal nature in this shape, and once again, inspired by the more contemporary works of Alexander on The Nature of Order, I came to define the notion of Center in software in a couple of blog posts: Lost (September 13, 2008) ... and Found (September 21, 2008), moving past an early attempt made by Jim Coplien in the late 90s. Those now distant reflections brought me to emphasize the importance, in real life development, of the more concrete artifacts we shape (source code, models), as opposed to the more abstract and disconnected notion of syntax that lies at the foundation of traditional computer science.
Gradually, in my later works, I've indeed found it useful to move away from traditional concepts like syntax and semantics, and toward notions which more closely follow reality, like the artifact space, the run/time space, the decision space.
That was just the beginning of a long journey; after 30 years of programming, I was looking at software in a different way. Notions like paradigms, principles, rules, and patterns faded into a familiar background, as I began looking for deeper concepts. I realized that -ilities often encoded some notion of property (akin, for instance, tensile strength in physical objects) but we didn't have any understanding of forces (like, along the same lines, tension). No wonder we're often left with little more than our rhetoric ability when it comes to justify design choices.
I kept looking, not by concocting some abstract notion in the safety of an office, but by observing real software in the real world. This led me to publish, between 2008 and 2012, 18 long blog posts where I explored my findings, under the unappealing title of "Notes on Software Design". Perhaps the best way to understand my goal is to read Notes on Software Design, Chapter 0: What?, which came out after Chapter 5, as I had little idea of what I was after in the very beginning. A reasoned summary of the other 17 chapters can be found in the Papers page. A few are now obsolete (or plain wrong) in light of what I've learned since their time.
In 2013, I decided to shut down the blog. I've learnt a lot through this exploration, and it changed the way I see software design forever. I now see angles I couldn't see before, and I can think of new shapes I wouldn't have imagined before. It's also incredibly effective to apply those notions as I come across new ideas in programming paradigms and languages, libraries, tools, architectures.
Still, it proved too unpopular to thrive. I didn't want to (or perhaps I couldn't :-) play the guru game, where notions, principles, and rules are pushed through rhetoric, appeal to a primordial lust for "purity", social pressure to belong to an enlightened elite or just to do what cool kids do. I tried to approach this journey through (dare I say it) scientific observation of reality and a detached analysis of what really happens to software in the real world. As a result, I wasn't paying homage to any cool trend. In many cases, my reasoning went against cool trends. It was probably too unconventional to get any traction. Most people, even those who appreciated my work, didn't feel comfortable with the idea of sharing it with their peers. In short, it didn't work on the social sphere, and therefore it never gained any traction.
Meanwhile, I was reading the early works of Christopher Alexander, like Notes on the Synthesys of Form, which predates his work on Patterns. The idea of shape (form) as a reaction to (and at the same time as a mirror of) external forces began to settle in. I wrote a few posts where the notion of decision struggled to emerge (On the concept of Form (1), Architecture as Tradition in the Unselfconscious Process, On the concept of Form (2), On the concept of Form (3): the Force Field). In hindsight, I can see how viscosity, a term I reused from Alexander's work, could be better modeled as friction in the decision space. Back then, I had no idea :-).
Giving shape to software requires that we keep some portions together, others apart. There is an intrinsic fractal nature in this shape, and once again, inspired by the more contemporary works of Alexander on The Nature of Order, I came to define the notion of Center in software in a couple of blog posts: Lost (September 13, 2008) ... and Found (September 21, 2008), moving past an early attempt made by Jim Coplien in the late 90s. Those now distant reflections brought me to emphasize the importance, in real life development, of the more concrete artifacts we shape (source code, models), as opposed to the more abstract and disconnected notion of syntax that lies at the foundation of traditional computer science.
Gradually, in my later works, I've indeed found it useful to move away from traditional concepts like syntax and semantics, and toward notions which more closely follow reality, like the artifact space, the run/time space, the decision space.
That was just the beginning of a long journey; after 30 years of programming, I was looking at software in a different way. Notions like paradigms, principles, rules, and patterns faded into a familiar background, as I began looking for deeper concepts. I realized that -ilities often encoded some notion of property (akin, for instance, tensile strength in physical objects) but we didn't have any understanding of forces (like, along the same lines, tension). No wonder we're often left with little more than our rhetoric ability when it comes to justify design choices.
I kept looking, not by concocting some abstract notion in the safety of an office, but by observing real software in the real world. This led me to publish, between 2008 and 2012, 18 long blog posts where I explored my findings, under the unappealing title of "Notes on Software Design". Perhaps the best way to understand my goal is to read Notes on Software Design, Chapter 0: What?, which came out after Chapter 5, as I had little idea of what I was after in the very beginning. A reasoned summary of the other 17 chapters can be found in the Papers page. A few are now obsolete (or plain wrong) in light of what I've learned since their time.
In 2013, I decided to shut down the blog. I've learnt a lot through this exploration, and it changed the way I see software design forever. I now see angles I couldn't see before, and I can think of new shapes I wouldn't have imagined before. It's also incredibly effective to apply those notions as I come across new ideas in programming paradigms and languages, libraries, tools, architectures.
Still, it proved too unpopular to thrive. I didn't want to (or perhaps I couldn't :-) play the guru game, where notions, principles, and rules are pushed through rhetoric, appeal to a primordial lust for "purity", social pressure to belong to an enlightened elite or just to do what cool kids do. I tried to approach this journey through (dare I say it) scientific observation of reality and a detached analysis of what really happens to software in the real world. As a result, I wasn't paying homage to any cool trend. In many cases, my reasoning went against cool trends. It was probably too unconventional to get any traction. Most people, even those who appreciated my work, didn't feel comfortable with the idea of sharing it with their peers. In short, it didn't work on the social sphere, and therefore it never gained any traction.
Recent past and near future
None of those papers represents my current perspective on things. My writings never caught up with my understanding. There is really just too much to say when you start questioning the fundamentals, beginning with the need to get rid of a muddy terminology and many flaky notions that have kept us in the stone age for years. I have hundreds of notes, dozens of unfinished papers, etc. I never had a chance to talk about so many things. I also need to think much, much more about a few thorny issues. I’m occasionally publishing some of my most recent thoughts in the random notes section of this website.
My presentation “Software Design and the Physics of Software” at DDD EU (January 2016) somehow breathed some new life into this work (it was recorded, so follow the link to watch). Although a few people hated it, and quite a few thought it was still incomplete / theoretical (which is partially true), more than a handful showed genuine interest and appreciation, so there is perhaps some chance for these ideas to spread a little.
I've recently added a new paper on Compressive Strength and Parameter Passing in the Physics of Software (see papers).
I talked on what I consider "applied physics of software" at nCrafts in Paris (May 2016), presenting “On Growth and Software” (this too was recorded, so follow the link to watch). A report of the experience is here. The talk centers on properly defining "ease of extension and contraction" as a symmetry in growth model between the decision space and the artifact space.
I'm still working on ideas to formalize and compare the other common, informal term "flexibility" (often confused with "extendibility" but actually a distinct concept).
My presentation “Software Design and the Physics of Software” at DDD EU (January 2016) somehow breathed some new life into this work (it was recorded, so follow the link to watch). Although a few people hated it, and quite a few thought it was still incomplete / theoretical (which is partially true), more than a handful showed genuine interest and appreciation, so there is perhaps some chance for these ideas to spread a little.
I've recently added a new paper on Compressive Strength and Parameter Passing in the Physics of Software (see papers).
I talked on what I consider "applied physics of software" at nCrafts in Paris (May 2016), presenting “On Growth and Software” (this too was recorded, so follow the link to watch). A report of the experience is here. The talk centers on properly defining "ease of extension and contraction" as a symmetry in growth model between the decision space and the artifact space.
I'm still working on ideas to formalize and compare the other common, informal term "flexibility" (often confused with "extendibility" but actually a distinct concept).
