In computer programming, global variables are sometimes a convenient shortcut. However, they are discouraged for larger programs as anything happening to a global variable results in a large part of the program getting affected. In such cases, the cost of detecting the extent of impact and correcting them exceeds the benefits of global access to the variable. In design terminology, this condition signifies lack of modularity, and is plain BAD! On the other hand, in economics, we have many global variables. We have middle east for oil. Japan for motor spare parts. Asia for cheap intellectual labour and so on. If anything happens to any of them (as happened to Japan recently), the impact is immense and damages incalculable.Going by the tradition of modularity as observed in engineering discipline, we would probably have done well to engineer our society in smaller modules, and limiting interaction between disparate modules to the bare minimum.
The principles of modularity has another important lesson. While we use encapsulations (i.e. hiding details within modules from other parts of the program) a lot in computer programming, the read-only access is a lot more liberal than read-write access. The socio-economic equivalent to this situation could be that we decide that there remains much less restriction in the flow of information than restrictions on flow of goods. Going by this principle, things like right to information, lokpal bills etc. would be encouraged. On the other hand, patents and copyrights, export and import would be discouraged.
Of course, this thought, though interesting for sure, has difficulties:Legacy. The human civilisation is the oldest, biggest and most complex legacy system that we have to deal with. It's been under construction since much before concepts of good design were known even in the field of engineering. So, strictly speaking, we are maintaining it rather than designing. It's ridden with lack of modularity, redundancy, inefficiency and dead-code. Attempts to correct it have more often than not resulted in genocide and war. However, like it happens in software system, a lot more stuff gets added to the economy at an ever accelerating rate as time passes. Ideally, we should apply principles of good design in what we add. Quite ironically, it doesn't happens. Our economics is more and more globalised than before. It's funny that something similar happens in the software world. A software system is usually at its best when it begins its life. It's design superiority deteriorates progressively through its maintenance phase, eventually leading to its obsolescence.The Human Element. The elements of the socio-economic system are -- ah! the ancient problem -- humans. They can't simply be asked to pretend not to know how to reach out and seek connections.Definition of Modules. How do you define boundaries for socio-economic modules? Geographical proximity? What should be the ideal size? National populations? What's the measure of size? Population? Area? GDP?Apart from these fundamental difficulties, the fact remains that running, maintaining or designing the socio-economy is an act more akin to industrial software engineering, where it turns out to be critical that we respond quickly to emergent situations and market pressures, than to cleanroom software design where we have the luxury and time to follow good principles. But we mustn't forget that while we design our socio-economy, there's no external customer, no competition, no time-to-market pressures. Yet, all the haste gets created within the system all the same!What's the hurry? What's this speed achieving? And more than that, this speed is of what?Where do we want to get? Where are we really leading our society to?
These are more philosophical questions, though.
These are more philosophical questions, though.