Network science and software

Back in January, I read Albert-László Barabási’s Linked: The New Science of Networks, hoping to get some ideas for software development and software architecture. In this regard, it was rather disappointing – although I thought it was a very interesting book at the time.

I tried to link networks to design principles such as low coupling and high cohesion. As for low coupling, I related this to hubs, which are nodes with much greater number of links than other nodes in the network. In software, hubs are generally bad – or at least constitute spots in your code where you should be wary, as changes are more likely to cascade and affect a larger part of the system. (I will return to this in a future post.)

And regarding high cohesion, I thought about this as the “fitness of a node”, suggesting that highly cohesive objects would attract more users (along the lines of the paper The Selfish Class, by Brian Foote and Joe Yoder). High cohesion, I wrote, is about classes and modules constituting intuitive wholes; that their sets of responsibilities fulfilled make sense as units. I thought about software as networked ecosystems, where classes would compete based on their fitness. High cohesion would only be one factor in a node’s fitness, among other things such as quality, utility, et cetera.

I interpreted this as something I would read about later, in Complexity: The Emerging Science at the Edge of Order and Chaos by Mitchell Waldrop (warmly recommended) – namely complex adaptive systems. I envisioned systems where multiple XML parsers would co-exist, and the system would learn over time when to use which. One parser would be more efficient in dealing with shallow documents, for instance. The parsers would be nodes and the “operating system” would rewire them based on feedback.

I was reminded of Richard Gabriel’s Mob Software (which I recommend warmly), in which he says programming tools and languages should facilitate maintenance – that making changes and adding new features is repair. Software development is often seen as being about drafting plans and building systems according to them – when in fact it is much more organic.

In Linked, Barabási mentions that in graph theory (a forerunner to network science), growth was never considered: they always worked with graphs that had fixed numbers of nodes (and possibly even links). As network science took off, they found that without growth, scale-free topologies don’t emerge – and as scale-free topologies have been observed in a wide range of networks, growth is central to network thinking.

So, instead of thinking of software development as building systems according to plans, we should see it as growing or evolving them to become whatever the plans say. I think this is an important distinction, as you assume that growth (and therefore change) will take place. The plans then turn into visions rather than specifications.

But on the whole, Linked didn’t offer me much in my search for the truth in software development – which is evident from the strange connections I tried to make between networks and software. But it has stayed with me and I often find myself thinking of things in terms of networks.

The above was posted to my personal weblog on May 8, 2003. My name is Peter Lindberg and I am a thirtysomething software developer and dad living in Stockholm, Sweden. Here, you’ll find posts in English and Swedish about whatever happens to interest me for the moment.


Related posts:

Posted around the same time:

The seven most recent posts:

  1. Tesugen Replaced (October 7)
  2. My Year of MacBook Troubles (May 16)
  3. Tesugen Turns Five (March 21)
  4. Gustaf Nordenskiöld om keramik kontra kläddesign (December 10, 2006)
  5. Se till att ha två buffertar för oförutsedda utgifter (October 30, 2006)
  6. Bra tips för den som vill börja fondspara (October 7, 2006)
  7. Light-Hearted Parenting Tips (September 16, 2006)