In our last post, we discussed the different perspectives of software and how it affects the approach to Open Networking solutions by different stakeholder groups. In this Part 4 of the Open Networking Software Interlude, we look at the software development process – but what is software development?
What is Software Development?
It seems that when people talk about “software development” they mostly are thinking about the process of creating source code (editing text files), and then compiling, debugging and building these text files to produce the final executable software components. This is such a strong view that some software teams use it as a trope.
That’s a common view if the person has at least some level of understanding about the software process. If not, there can be a view that developers just “ do stuff” and software happens.
But is that what programmers do?
What do Software Developers do?
Software developers do a lot of things when they are working, e.g. they read documents, they talk to target end-users, they talk to each other and have meetings, they review user stories, they have coffee and go to the gym. And sometimes they just sit at their computers, or just sit. And sometimes they write code.
Unless you’re already experienced in software development projects, developers can do a lot of things that don’t actually look like working.
But, unlike many other professions, all these activities can be taking place at the same time as actual software development is taking place. Some analogous professions (such as writing and music) have similar characteristics but they are few. How can that be?
Also, there is one very significant distinction from all other analogous professions: none of them have to take the results of this mentally intensive processes and feed them into an unforgiving rule-based technical realisation process, i.e. a software build that produces executable code, before the results of this work can be captured. There is no sub-editor as strict and ruthless as a compiler.
No, Really, what do Developers do?
One important and useful idea of software development was described by Peter Naur as “theory building”, i.e. developers are building a theory of the world that generates the problems that needs solving.
”…it is concluded that the proper, primary aim of programming is, not to produce programs, but to have the programmers build theories of the manner in which the problems at hand are solved by program execution.
-- Peter Naura Danish Computer Pioneer
I would argue that developers are creating multiple “theories” concurrently: one of the current “real world” problem domain, another of the real-world solution domain, and a third model of how the software itself should be designed.
Researchers have associated this idea of building a “theory” is essentially creating a “mental model” about the problem to be solved and potential solutions. Jorge Aranda wrote a PhD thesis about mental models in software development teams:
A “mental model” is a cognitive construct that describes the way in which someone thinks about part of the real world in which they exist and operate. Like other models it represents a subset of the real object(s). “Mental models” govern behaviour, reasoning and decision-making, amongst other aspects of human thinking.
Thus developers need to build their own internal mental model of the domain being automated; and, working in teams, those mental models need to be closely aligned and consistent with the mental models of other developers and other key stakeholders in the development process, i.e. building “shared mental models”.
How well formed and detailed the developer’s mental model is, the more likely the software will be to perform its job correctly. This relates directly to the quality of the information available to the developers.
What does this mean?
This “theory building” or “model building” concept of software development is very powerful: it informs much of the agile software development principles that are predicated on both direct access to business representatives and constant dialog between them and the developers. It explains many of the reasons why earlier approaches to software development (which were dependent on document specifications as input to the software development process) have been so problematic.
We have described two very different, and largely incompatible perspectives on the process of software development. On the one hand a focus on the external, physical tasks of writing and producing code and working (essentially) from other stakeholder’s analyses of the problem domain.
On the other hand we posit a highly internalised cognitively intensive view of software development as “theory building” which also requires direct access on the part of the developers to the actual problem domain (people and processes).
This difference in development perspectives and the understanding of software development dynamics are tremendously important to the development of Open Networking solutions.
We’ll describe the implications of that problem in future posts.
Stay tuned.
