used the GOTO statement as their means of controlling the flow of execution. For
anything but the simplest of programs they also had to be documented with a flow
chart so that you could get a visual representation of the structure of the program.
Complex programs were likened to a bowl of spaghetti since they had a similar
"structure".
Eventually we came to recognise that the "structured programming techniques" of
languages like Algol could untangle the spaghetti and allow more complex programs.
By restricting ourselves to a small set of conditional, loop and subroutine calls we
were thus able to build more complex programs.
As time went by it started to become clear that there was a new limit on complexity
emerging. Since any code could access any data large programs became difficult to
manage as different parts of the program treated the same data in different ways, or
attributed different meanings to it. The spaghetti had seemingly moved into the data
structures.
The next evolution was the object oriented paradigm. Access to data was localised.
This worked well for a while, but as programs grew in size it started to become
difficult to visualise the flow of control between the objects. For any large program
sequence and collaboration diagrams became a necessity. The spaghetti had moved
back to the flow of control.
The latest evolution, termed Service Oriented Architecture, aims to overcome this
complexity by dividing the system into smaller, simpler programs interconnected by a
standardised message passing infrastructure. The smaller programs should be easier
to understand and test.
Unfortunately the spaghetti has now escaped onto the network, and we are unlikely to
ever be able to get it back under control. We are now destined to create systems
which are non-deterministic and which are likely to have unexpected emergent
behaviours.
This work is licensed under a Creative Commons Attribution-ShareAlike 4.0 International License.
No comments:
Post a Comment