Linked #3

(More thoughts from reading Barabási’s Linked.) In software design, there are two desirable properties most commonly referred to as low coupling and high cohesion. Within the framework of networks thinking, the former seems quite odd, as it is about limiting the number of “links” between “nodes” – or, dependencies between parts such as modules, packages, and classes. A design that has low coupling is more amenable to change, since it reduces the probability of changes cascading and affecting a larger part of the system.

High cohesion seems to be related to the “fitness” of a node. As I wrote in my previous post, they first found that preferential attachment based on the number of links of nodes – that is, that new links were more likely to be made to nodes that already had many; a principle Barabási calls “rich get richer” – resulted in the scale-free topology they found as they analyzed the structure of the Internet. Later, they discovered that preferential attachment often rather was based on the fitness of the network’s nodes – otherwise Google’s success would have been impossible, since it was a latecomer and there already were very large hubs in the network (AltaVista, Yahoo!).

Anyway, high cohesion is about classes and modules constituting intuitive wholes; that the set of responsibilities that a class or module fulfills simply makes sense; that there isn’t any responsibilities that stand out against the rest – such as an XML parser which also has functionality for calculating annuity payments for mortgages. So, high cohesion seems to be related to fitness, and to me it suggests regarding software as networked ecosystems, where classes compete with each other, such that the fittest wins (see my post on The Selfish Class). Cohesion would be far from the only fitness parameter, though. Others, such as quality, utility, etc, would be more significant.

So, with a network paradigm in programming, adding features would perhaps be about adding nodes and letting them compete with other nodes. If the XML parser isn’t good enough, add a new XML parser node that is fitter (perhaps the fitness of a node is even determined by the programmer, so that he has more control over the network) and thus wins over the previous one. The compiler would, besides compiling individual nodes, also link them to each other. Perhaps linking would take place at runtime, also, so that the network can adapt to it’s use. Let’s say for the sake of example that you have two XML parsers, one that is faster for shallow documents, and one that handles deep documents better. If the users of the system feed more deep documents to it, the XML parser nodes are rewired to make the system more efficient.

Richard Gabriel talks about programmers being in need of tools to facilitate maintenance, since the larger part of development projects are about maintenance. If I understand him correctly, adding new features and making changes is repair. You approach the development of a system in an iterative, incremental fashion, making successive repair work, correcting the system as the team’s shared mental image of it takes form. You begin with a small system, get feedback from customers and users, and repair it based on that feedback. This is in contrast of extending the system by constantly inventing new parts to add to it. ––– I’ll have to continue this later.