In our last post, we discussed why software development (and managing software development projects) is so hard. In this Part 6 of the Open Networking Software Interlude, we look at the generic paradigms for building things and use that to compare those of the different areas we encounter in Open Networking.
Open Networking integrates together many practices, technologies, occupations and even organisational units which have previously been quite distinct and separate. Bringing these together highlights some intrinsic differences in approach, and understanding these differences enables us to manage them.
Preliminary – the three elements of building things
Humans have a long history of “building things”, be they civil engineering projects (e.g. Suez and Panama Canals), religious edifices (e.g. the Pyramids of Giza or Christian Cathedrals) or new industrial products (e.g. the Model T Ford), or even relatively commonplace modern projects such as multi-story skyscrapers or the development of new software products.
Throughout this history, there have been many different approaches to how these new things got built. One differentiator is the “stuff” from which these new things were built: stone or steel or concrete or software.
Another differentiator is the arrangement and relationship between three key elements of each project: “design”, “production” and “management”.
- Design: the analysis of needs and the specification of both a thing to be built and (where appropriate) the processes and mechanisms for building it;
- Production: the processes and mechanisms for building the new thing (think: a manufacturing line in a factory); and
- Management: the control of the end to end process, procurement and assignment of resources etc (Henry Fayol and successors)
It is beyond the scope of this post to go into this in great detail, but in summary the historical evolution of development has resulted in the progressive separation of “design”, “production” and “management”.
This ranged from prehistorical times, when all three were essentially merged into one entity, typically including a king or head of state (often equated with a “god in human form”), to modern industrial processes, in which all three are progressively disaggregated and separated along multiple dimensions (professional, organisational and legal/administrative).
This progression continued steadily until the invention of software development.
Early approaches to software were based on non-software industrial and engineering processes in which these three elements were quite distinct and separated. This led to the rules-based and serialised implementation strategies (e.g. the Waterfall) which were efficient from a management perspective and well-understood based on established practice.
But we all know how troublesome that has been (and remains) in software development projects.
This has changed in the last 20 years or so. Whilst agile has introduced many things, one of the fundamental paradigm shifts in agile software development has been to re-integrate “design” and “production” into the same process, organisational and management structures.
“Theory Building” and Design
From the idea that software development is largely about building a theory about a problem and the solution, it isn’t too far a step to generalise this very technical and specific activity into a very common one: design.
The term “design” has many meanings but at its core it is a problem-solving exercise intended to create a solution that meets many requirements.
By aligning the idea of “theory building” in programming to the idea of design generally, we can take a perspective on software and software development that compares and aligns it with other productive activities and the fundamental breakdown into “design” and “production”.
In software development, “design” and “production” are integrated into the one process: the more tightly integrated are, in practice, the better the software development process works. And the more separated they become, on balance, the less successful the process is.
Contrast this with an industrial process, for example the mass market products domain. Here, a product is designed and then a factory manufactures many copies of this design: there is very little overlap between the two phases and each phase is performed by different people or groups: even different organisations.
So in this case, “design” is very separate from “production” and there are fairly robust practices to help ensure that this separation doesn’t result in design defects being manufactured and distributed to customers. Even so, this is not a rare occurrence.
Other engineering works, for example Network Engineering, seems far more related to the separate “design” and “production” paradigm than it does to the combined paradigm. These paradigms can be deeply entrenched, often unconsciously, in the thought processes, tools, and even operating procedures that surround the development of each type of solution, and to a large extent, these paradigms are highly incompatible.
What does this mean for Open Networking?
What is the implication for Open Networking? Because of the wide net cast over the components of Open Networking practice, it is inevitable that multiple paradigms become enmeshed in the same projects, working on the same things. In many projects this doesn’t occur, being either mostly software or mostly hardware. But in Open Networks, these incompatibilities are both stark and widely distributed.
This can lead to significant dissonance that must be recognised and managed carefully.
We will address this in more detail in a later post.
Stay tuned….
