Over the last 60 years, we have tried to push the development of software from being a craft to an engineering discipline. Today, the expression “software engineering” is use commonly to describe the activities surrounding creating a dependable, functional piece of software. Despite the great advances which the software community has provided with regards to defining better controlled processes and methodologies for developing software, we often here people say that software creation is part art part science.
So… is it that we have not currently reached the holy grail of software development methodologies which will liberate us from the chains of the arts and crafts aspect of developing software, hence propelling us into a new age of software engineering nirvana….. or are we searching for a mythical dragon that doesn't exist ?
When we associate terms such as engineering, process, and methodology to the activity of creating software, we are implicitly casting software as a technological construct. A technological construct is an object which has meaning and existence outside the influence of people. At the opposite, a social construct only has meaning in the context of a society. For example, a bridge is a bridge. One can talk about a bridge without making reference to a given social context. In contrast, one cannot talk about concepts such as “respect”, goodness without making reference to a given societal context. Each social group will define what it means to “respect others” differently. Technological constructs can be define rigorously using symbols such as mathematics and blueprints to define what they are... they can be engineered.
I have been recently pondering the idea that software is mostly a social construct; especially software developed in the context of organizations. In these contexts, software often plays the role of a human being (albeit an automate one) participating in business processes characterised by complex webs of interacting individuals. Moreover, these processes are most often executed in similar ways but never exactly the same because contexts are never the perfectly the same and people never behave the same. In order for complex tasks such those found in organizations to be accomplish by teams of people, it is necessary for the team to develop “shared meaning” about what most be done and how they should work together. This “shared meaning” about the “what” and the “how” is a social construct… it is establish through dialogue and shared experiences amongst the team members. If software must take part in one of these webs of human interactions because it replaces one of the team members, one could probably argue that “what” the software should accomplish and “how” it should to it is also a social construct because different social contexts (organizations) will probably have different “shared meaning” on the matter.
If this is such, software is a social contract. Consequently, one can only define software through a continuous dialogue of “shared meaning” creation. The process of using upfront specification which are than used to “engineer” the final product cannot work… only iterative process which verify often the congruence of the software with the “shared meaning” of role it should play can work…..
So… is it that we have not currently reached the holy grail of software development methodologies which will liberate us from the chains of the arts and crafts aspect of developing software, hence propelling us into a new age of software engineering nirvana….. or are we searching for a mythical dragon that doesn't exist ?
When we associate terms such as engineering, process, and methodology to the activity of creating software, we are implicitly casting software as a technological construct. A technological construct is an object which has meaning and existence outside the influence of people. At the opposite, a social construct only has meaning in the context of a society. For example, a bridge is a bridge. One can talk about a bridge without making reference to a given social context. In contrast, one cannot talk about concepts such as “respect”, goodness without making reference to a given societal context. Each social group will define what it means to “respect others” differently. Technological constructs can be define rigorously using symbols such as mathematics and blueprints to define what they are... they can be engineered.
I have been recently pondering the idea that software is mostly a social construct; especially software developed in the context of organizations. In these contexts, software often plays the role of a human being (albeit an automate one) participating in business processes characterised by complex webs of interacting individuals. Moreover, these processes are most often executed in similar ways but never exactly the same because contexts are never the perfectly the same and people never behave the same. In order for complex tasks such those found in organizations to be accomplish by teams of people, it is necessary for the team to develop “shared meaning” about what most be done and how they should work together. This “shared meaning” about the “what” and the “how” is a social construct… it is establish through dialogue and shared experiences amongst the team members. If software must take part in one of these webs of human interactions because it replaces one of the team members, one could probably argue that “what” the software should accomplish and “how” it should to it is also a social construct because different social contexts (organizations) will probably have different “shared meaning” on the matter.
If this is such, software is a social contract. Consequently, one can only define software through a continuous dialogue of “shared meaning” creation. The process of using upfront specification which are than used to “engineer” the final product cannot work… only iterative process which verify often the congruence of the software with the “shared meaning” of role it should play can work…..
Posts
