Another Babel tower in the making ...!
There are plenty of abstractions and mystifications surrounding the
aspects of production in software industry. And this has been helping many forces
of monopoly and hegemony for more than two decades now. There may be corporate interests and economic reasons behind this,
which can be better understood only if we unravel the cognitive, mechanical and
economic factors involved. Rather than taking a rhetorical line, let us
approach this dynamics in a historical and engineering perspective. While
analyzing the structural fabric of this field of production, the macro-economic scenario is not widely discussed.
The history of commoditization in the field of software production is
pretty unique. It may be due to the fact that this is a rare twist in the
direction of industrial production. If we trace the dynamics of industrial
production, we could see that from the inception of modern machines running on
advanced thermodynamic and Newtonian mechanic principles, we saw tremendous progress
of automation in the nature of machines. And all these progresses in the level
and range of automation transformed the laborer in the production line. This
must be due to the fact that we were harnessing the forces of nature (such as
gravitational force, electromagnetic force, nuclear force etc) in all these
fields of production. This was enough to create an illusion of techno-centric
capitalism where machines are ruling the roost. Even the notions of
post-industrial societies emerged in this wave of events. Apparently, with the
expansion of capital markets, capital became seemingly more mobile than the
labor!
Thus the importance given to the human craftsmanship gave way to the
efficiency and productivity of machines. Laborer became the enabler and
initiator of various modes of production. When the machines were transformed
into a commodity, they attained a certain level of standardization and
capitalism was able to organize its mode of production very quickly. The
increasing nature of commoditization lead to monopolization further and further
and it continues even today to higher levels. Thus entry barriers and levels of
competition in these fields of production rises high day by day steeply and
stealthy.
Though there are some streams of thought which treat software programming community entirely as a human capital and this entire system as an information economy, I would like to reject that proposition. A software engineer is not sold by itself here in the market. It is a wrong notion. This is because of the fact that the knowledge of the programmer or the software engineer is still very much abstracted out from their existence and it becomes the commodity. Thus in software industry the circulating energy is this knowledge which is nothing but what we fondly call as ‘information’. In the history of mankind, first time knowledge has become the labor force. But it should not make us glorify the whole scenario as ‘knowledge economy’ as still this economy is very much enshrined in the portals of finance capital. At the same time, we cannot ignore the fact that the privatized educational systems in emerging countries like India , Brazil , and Philippines are treating engineering students like human capital, as if to justify the concocted theories of these economists! This aspect need a different study altogether.
Now if we look at the history of software engineering, with each
breakthrough in the field of programming and the complexity of computation, the
creativity of the human mind got further and far reaching prominence. It is
because, as and when the computing machines are getting complex and smarter,
the human mind is also expanding its horizons. The software engineers
world-wide are able to feed more and more complex algorithms and break further
and further into the kernels of encryptions. This race between man and his
machine is like an ever expanding spiral generating more and more knowledge
paradigms. The freedom expressed by human mind in this field has not become a
freedom for the human labor. Here, history repeats itself. Despite this
explosion of creativity, software production has got chained in the same old
capitalistic mode of production. And this irony is in our scope of study.
Thus software labor is not leading us to the earlier days of
craftsmanship. As we know, there are no retreats in the history of mankind.
Instead, we are seeing a conflicting production line where the conventional
modes of production and a new form of abstracted labor force working together. In
the multinational software factories, we see domination of more and more tools
of scientific management. This was brilliantly summed up by Harry Braverman, an
Industrial Sociologist. He wrote Labor
and Monopoly Capital: the Degradation of Work in the Twentieth Century,
which provided a critical analysis of scientific management. Within Braverman’s
model Capital needs to dominate the labor process and weaken the ability of
workers to resist. Braverman placed considerable emphasis on the role of
Scientific Management (Taylorism) as a quintessential method of achieving this.
In particular, Scientific Management involves the subdivision of tasks and the
establishment of new technologies that are less dependent upon worker’s craft
skills.
Analyzing on these lines, we can see that like any other conventional
industrial work, software labor has been successfully fragmented into various
tasks by technologies of scientific management. This deskilling of the labor
has become the inherent nature of a normal software production process. Through
task fragmentation, the planning or conception part of the work process is
separated from the execution part, and the skill requirements and job learning
time are reduced to a minimum. This system is known in the literature as
‘Taylorism’ or ‘Fordism’ and it is one of the characteristic features of the
capitalistic division of labor.
We can measure it based on a few parameters.
- Is there
a decline in skilled content in the job?
- Is there
a separation of mental and physical labor?
- Is there
a decrease in the levels of training?
- Is there
large increase in the maintenance projects?
The historic transformation of software production process was
illustrated by Joan Greenbaum(1976, 1999) as follows :
“During the first phase, in the early days of computer use, there was
no clear-cut division of labor and software work was more like a craft
activity. During the second phase – ‘capital took control’- ‘programmers’ were
separated from ‘operators’ in the workplace and the new occupational subgroup –
‘system analysts’ – emerged. System analysts developed procedures to process
information and find solutions to business problems, while programmers
translated these solutions into a language the machine could understand. In
this phase, a division of labor had emerged with different task sets, pay
scales and training requirements.” These phases are grouped into 1950 – 65,
1965 – 70, and 1970 – 75.
Going along these lines, the pioneering study of Philip Kraft (1977,
1979) is worth attention. He identified three instruments for the routinization
of software work: use of high-level languages, canned programs, and structured
programming. He traces this back to the
Korean-war era SAGE project, with the separation of “conceptual”
computer-program design work from the “mechanical” labor of inputting of code.
High level languages involved a degree of separation from the assembler level
languages and allowed more abstract, logical programming to take place. In this perspective, a programmer could learn to use these higher-level languages without
understanding assembly-line code and thus, required less skill and education in
order to be productive.
According to Kraft, structured programming was a rejuvenated Taylorist
approach to programming, involving the minute separation of tasks, a strict
hierarchy of labour and a rigid set of standard procedures and protocols
governing work practices. With this system, a few elite professionals could
perform all the intellectual, creative work, and pass all the rest of the
construction of the software down to discrete ‘modules’ of workers, who would
specialize in writing a single piece of the code. For these workers, almost no
skills and experience were required to assemble discrete fragments of programs,
and thus, they could be paid far less than the elite systems analysts and
engineers.
In his own words:
“Structured programming, in short is the software manager’s answer to
the assembly line, minus the conveyer belt but with all the other essential
features of a mass production work place: a standardized product made in a
standardized way by people who do the same limited task over and over without
knowing how they fit into the larger undertaking’”.
If we follow Kraft further, we can see his notion of routinization. The routinization of labor is reinforced by two institutionalized
means: nature of training and career structure available to software workers.
In this effect, low-level programmers experience merely a horizontal movement
in the organization. It can be termed as virtual promotions. They may get
slightly increased pay and their title may also change, but their nature of
work remains the same. They move from project to project many a times doing the
same job. However we should note that, Kraft and Greenbaum were criticized for
their political bias and lack of in-depth understanding of software work.
As per Vigneshwara Ilavarasan and Arun Kumar Sharma from IIT Kanpur,
the low skilled nature of Indian software industry provides the opportunity for
routinization. They put forwarded the following six hypothesizes to test whether
software work in India
is routinized:
- Software
professionals are clearly divided into conception and execution workers,
such as designers, coders and testers.
- Execution
workers do not participate in the conception part of the project.
- Workers
involved in one module do not have knowledge of the other modules in the
same project.
- Training
requirements differ for different categories of workers.
- Career
opportunities are restricted for execution workers.
- Quality certification procedures enhance managerial control.
Their findings are worth detailed analysis and debate. It is available
on the following link:
Such being the level of task fragmentation in a relatively older programming paradigms, one may wonder about the level of task fragmentation in the new paradigms like object oriented programming, unified modeling language and aspect oriented programming, and test driven development. Reflecting on the current software development process, we need to explore whether the development methodologies like Waterfall, Agile and Scrum are dominantly incorporated with management strategies rather than code quality guidelines. Even the present prescribed standards of code quality need a debate. And we need an objective evaluation of the concept of deskilling in the present day. There are larger variations in this among software companies of different strength and different capability maturity model.
With the advent of breakthroughs like open
source model, free software movement, virtualization and cloud computing
paradigm, the software economy is undergoing rapid changes. The cost of
software production is becoming more and more affordable and standardized with
the advent of mobile computing and cloud based infrastructures. If in the
future we witness open-source grid computing infrastructures the cost of
production and distribution of software will become further more level playing
field. However, this task fragmentation seems to have eaten up the space of a 'software engineer' in its totality. And like any change in the course of history, one may attribute a sense of necessity to this change and advocate its continuity. At the same time, we need to see how this whole process will transform the software worker. There is always a break-even for any process in nature.
References:
- In an Outpost of the Global
Economy: Work and Workers in
- Is Software Work in
- Industrial Sociology: A comprehensive approach By Osama Lari.
- The Software Industry in Emerging
Markets – By Simon Commander
