It is difficult to explain the software development job to people who don’t practise it.
But it is a popular job (there are many developers) and its results are relevant for those who do other jobs (everybody is somehow in contact with software). So, it makes sense to try to explain what software development is, also in order to debunk two very widespread cliché.

Cliché 1: software development being analogous, or at least amenable to industrial
production (or to the building industry).

Cliché 2: software development being an activity mostly suitable for the least sociable people, who don’t like to work with others.

Paradoxical platitudes, for those who work in software development. But widespread
platitudes, unhappily common even among software development managers, sometimes with devastating effects on organizational choices, and on personnel selection and training.

A complex job

Software development is a complex intellectual job, one in which social aspects (relationships and communication) are more relevant than technological aspects.

The essence of software development is gathering knowledge about an actual problem (the application domain, in a field such as banking or automotive or medical or military industry), and implementing this knowledge, via proper abstraction processes, in an information system [1].

The complexity of software development comes from three main causes:

• The problem to solve may be complex in itself, for the number of concepts and the complexity of the characteristics and of the relationships of these concepts.
• The definition of the problem and of its solutions is a social process, and it happens through the dialogue between who wants the new system (the customer) and those whose role is to realize it (the developers). In most cases, nor the problem nor the solutions are precisely defined at the beginning of development. They are progressively determined during the project.
• The solution to the problem is bound to the characteristics of the available technologies.

Every software project has its goals, to reach in order to satisfy the customer and the users (even when, as it usually happens, requirements are clarified during the development). It has a cost, which we want to be minimal. It has time limits, which are usually bound. It happens in an actual social context, with conditionings and cultural constraints.

Nor manufacturing, nor construction

A long tradition wrongly equates software development with manufacturing.

From this point of view, software development does not happen in an “industrial” way because it is still an young discipline, and we must do every effort to bring it in line with most mature sectors. Hence the idea of realizing software “factories”. Hence, also, a tendency to revive in the software development field organizational models based on the role specialization and on the sequentiality of the assembly line (one century later than
in real manufacturing…) [2].

In the real world, software development has not any resemblance with the process of industrial manufacturing. The proper manufacturing, the creation of thousands or millions of identical copies from a single stamp, in a software project has a percentage cost
close to zero. Software development has instead significant similarities with new product development, i.e. design. From the definition of earlier models to the writing of code in a programming language, all software development is, at various detail levels, a design activity.

The analogy of software development with the building industry is more recent, and surely more accurate, than the analogy with manufacturing, because it brings out the design dimension, and the uniqueness of the results of software projects.

But there is a basic difference between the building and the software development industries. In building, the separation of the design phase from the realization phase is very marked. Once implemented, the decisions taken during house design may be changed only with a lot of work, because the materials bear the weight and the inertia due to their physicality.

Software is different. The whole project is design, not only the first phase. And it is, most importantly, an abstraction design. The materials are abstractions, which can be changed
in whatever moment, during or after the project, in future evolutions of the software product. Even software changes cost labour, it’s true. But a lot less than what is needed to modify architectural choices in the building industry, because abstractions are more malleable than concrete and bricks.

A job done in an actual social context

The most known image of the software developer is the geek, a young man introverted and
pimply, who communicates the least that he can, and when he does it speaks an unintelligible jargon.

In the real world, software development is a job in which communication and relationship elements are essential. These aspects are shown, in an often realistic way, in the Dilbert cartoon [3], and are covered in a more systematic way in the classic Peopleware [4] and more recently in the works of Alistair Cockburn [5]. From the point of view of the game theory, Cockburn shows the cooperative element in the software development activities:

“Software development is a series of resource-limited, goal-directed cooperative games of invention and communication. The primary goal of each game is the production and deployment of a software system; the residue of the game is a set of markers to assist the players of the next game. People use markers and props to remind, inspire and inform each other in getting to the next move in the game. The next game is an alteration of the system or the creation of
a neighboring system. Each game therefore has as a secondary goal to create an advantageous position for the next game. Since each game is resource-limited, the primary and secondary goals compete for resources.” (Alistair Cockburn)

There are several social interactions important and instrumental for the course and the outcome of a project:

1. those between who wants the system to be developed (the customer) and who develops it (the supplier-developer)
2. those among the customer and the various stakeholders, future users included
3. those internal to the development group (which in many cases is not a single group, but a series of different groups that must cooperate)

The first relationship, between customer and supplier, shapes the contractual and economic aspects of the project, the development process, the way the progress made is controlled, the risks management, the requirements communication and management.

The second relationship, among the customer and the other stakeholders, influences the definition of priorities and of detailed requirements, the way to manage conflicts among
concurrent needs, the future acceptance of the system by those who shall use it.

The third relationship, internal to the development group, influences crucially the productivity and the quality of the development process and of the resulting end product.

---

References:

[1] – Philip Armour – “The Laws of Software Process. A New Model for the Production and Management of Software”, Auerbach 2004

[2] – Mary e Tom Poppendieck – “Lean Software Development”, Addison Wesley 2003

[3] – Scott Adams – “The Dilbert Zone”

[4] – Tom De Marco e Timothy Lister – “Peopleware: Productive Projects and Teams” , 2nd Edition Dorset House 1999 (1st edition 1987)

[5] – Alistair Cockburn‘s website, and of the same author “Agile Software Development” – Addison-Wesley 2001