Computer Programs

A program as a system is a thing, a physical object, it occupies space-time, it is material. You can “tap” on a running program (a program process in a computer), you can poke your finger at it! A running program is the physical part of a computer that performs the computations of that program as it runs.

A program as a physical object has different states (which represent the physical states of RAM and processor registers) at run-time, and the computer is occupied by physical processes/changes/interactions of its constituent parts during computation. These processes in the computer occupy some place in the physical world: the space in which the interacting parts of the computer are located, and the time during which the program (that is, the parts of the computer within it) performs the computation:

Once again: a program should be considered a system realization only when it is actually run and working, doing what it does for the sake of what it was written. This is rather counterintuitive, but the source code of a program is not a program, but only a definition of the program; the source code of a program in a version control system or simply in a file on a storage medium is only the description of the program. The program is what reflects the state of the program at the moment of its execution.

So programmers who think that their engineering work is finished at the moment of writing the source code—these programmers are deeply wrong, and this is a typical mistake. A whole DevOps (DevOps - Wikipedia, there is a similar version of this movement, SRE Site reliability engineering - Wikipedia) movement came out of recognition of this mistake—programmers recognized that they should not only perform the role of program code developers (Development), but also support the program operation on working servers (Operations).

Source code is a definition of a program (it is done in classes like any design, one source code describes many possible instances of a program), and before using it, it must be manufactured: compiled, assembled, placed in the RAM of the desired computer (possibly framed in some container beforehand) and transfer control to it.

Thus a program as a system is a process, and we are interested in the process that runs on the right computer (or computers—for example, client or cloud), at the moment when the program works and fulfills its function, its purpose. Clearly, it’s usually a long way from the source code to a working program like this.

The mistake programmers make when they think their source code is a program is exactly the same kind of mistake designers and constructors make when they think their system is the information models (formerly drawings) and other design and engineering documentation they develop. A map is not a territory, menus are not eaten, drawings do not fly, and source code does not store the values of its variables at run-time*.

Another mistake is to think of a program as a System-of-Interest, not just a definition of a System-of-Interest. A program is like a book: we are most often not concerned with the book, or even with the content of the book (the book text itself), but with what the book text describes. We care about the worlds described in the book, but not about the beauty of the writing itself (well, except for “real geeks” if we are talking about fiction, writing for the sake of writing). It is the same with programs: we care about part of the world described by programm, but not about the program itself (no more than the book and its text do). If you have a dry-cleaning order software, then you care about clothes that will go from dirty to clean, about the money you’ll be charged, about options for transporting things to and from the dry-cleaning. The programmer cares about the program, but that’s his own business: everyone else cares about how the program will handle the actual dry cleaning situation, and the programmer should care about that too. If the program is outstanding as a software, but the dry cleaning will not be possible with it, then this is a failure of the project! Information technology—they are just about definitions, look for the physical world behind them, the changes that matter!

Another mistake is to include only the software, but not the entire service that does some meaningful work. In corporate software development, customers expect the results of this development not so much the correct operation of the computer, but the correct operation of the part of the organization that this computer must support: the people in the organization must work together with the software according to a certain organizational algorithm. Software doesn’t work without people; you have to show the work of software with people. This joint flow of people and computers is usually called a workflow, although it is often called organizational process/procedures. The program-in-development is most often only a part of the target organizational process. And remember, it is hard for people to think about processes (including organizational processes, workflows). So the program here will be part of the unit/service/provider that will make the necessary changes in the physical world. The program itself will be the personal business of the programmer or a small team of programmers, it is reckless to hold it in the epicenter of attention as a full-fledged system realization.

The matter is further complicated by the fact that programs as information objects (information carriers/storage, including all their databases) can be lined up in long chains, in which on the basis of one definition programs or programs-with-people change other definitions, then another—and only at the end of such a long chain does the desired change of the world come. You can describe yourself for a long time, describe where to get your money, your intentions, write down the intermediate results of decision-making by all kinds of other programs and people in your computer and/or phone, but only at the end of a long chain of ordering air tickets you will be physically let on the plane: hundreds of very different programs, some of them known to you and some even unknown, are triggered to get that result in the physical world. If that result doesn’t happen, all those programs and people have worked for nothing. So don’t be lazy to untwist all these “definitions of definitions”, all the long chains of programs and programs-with-people until you get to the changes in the physical world for the sake of which everything is done. And then make sure the physical world is all right. Yes, it’s hard, but systems thinking forces you to turn your attention in that direction. This is important, the output of software in the physical world—it matters, if there will be no reliable and expected changes in the physical world, then the software development project need not to be done at all, after all in the physical world nothing will change!

In order for the client to get the result of the organizational process, this program must be configured, some data must be given to it, and employees must be trained to work with it. And the work of the entire organizational structure/organizational unit/service/provider as a whole (including the program assigned to this organizational structure) must be verified, not so much the work of the program itself. No one cares about the payroll software, but the payroll itself (you can think of it as dividing some heap of physical gold into parts intended for distribution to employees)—and if there is no payroll, programmers will have hard time to explain that everything is fine with their program, and that all the other employees who fill out the fields of this program incorrectly and press the wrong buttons are in the wrong. Program development projects often have parts for working with people (learning how to work with the program: you have to “make” those parts of people who will be able to do something useful with the program) and data with which the program will work. Don’t skip these parts! They are physical, they need to be “design” and then “make”: people need to be trained (and develop ways to do it, and ways to test results of training), additional software to set up (and check if everything is set up).

How do we find the real System-of-Interest that programmers eventually manufacture? For even a working program turns out to often work with definitions and documented definitions of some other system than the real system that changes the physical world!

It is simple: you should not look at the program itself, but at the data of this program (often they are stored in some database). The data describes some system—most often it will be the System-of-Interest in the project! This is what the system realization is which concerns all the people around the development! It doesn’t work 100% of the time, but it can be a good starting point for finding a System-of-Interest when there are a lot of programmers around.

If we are talking about a business trip accounting program, the System-of-Interest is what is described by its data, and will be changed (created, destroyed) as a result of the program. This is a business trip. Yes, the business trip is a process/work, but it is quite clear how to describe and account for it on the computer. To do this, you simply need to account for all the inputs to the business trip (participation/part-whole/composition relationship)—people as business travelers, tickets (travel documents, with different nuances of media relationship for those documents), etc. If we are talking about a program for a CNC machine tool, the System-of-Interest is the part described by the data from that program. The program describes the operation of the machine, and the machine is needed to produce the part. The goal is the part, the money from it, and everything else is just a chain leading to that goal. So you have to be careful with programs as System-of-Interest. We will discuss this in more detail when we discuss the project Systems-of-Interest.

Even in the software world (and the whole world is slowly becoming a software world) there may be such strange system realization as sessions—training sessions, or game sessions. For example, a game session consists of a player in the game state, a game server that remembers the state of the game world, running on the phone game program, which is controlled by the player on the one hand and the game server (via the Internet) on the other. All these objects mutually changing states are the game session. Business people will be happy with this definition of the System-of-Interest, for they sell these game sessions, and increase sessions’ total time! Note that none of the other systems mentioned here will not be enough to fully describe what is happening: neither the player himself while playing, nor the server software, nor the software in the phone, nor the payment system software (payment is usually just for game sessions, with slight variations!).

There is often confusion when software is a “marketplace”. Not only is the software of this “marketplace” considered a System-of-Interest, but they also ignore the data for this software, all the people serving this marketplace, all the customers of this marketplace, all the possible intermediaries and providers who work with this marketplace in order to end up with an system realization that someone will agree to pay for. No one is going to pay for “Marketplace”, it’s just one of the parts that will allow you to make money: a marketplace makes something that people need. For example, a marketplace can make a “delivery”: it is some product (thing!) that is in space right on the doorstep of the place where this very delivery is intended. This one “delivery” is the System-of-Interest, it is paid for, it is embodied in the physical world, it is manufactured, and everything else is just a chain of definitions, other systems leading to that System-of-Interest. “Delivery” will benefit customers, and everything else will only benefit the sellers-developers, by exchanging software for money.

Can we assume that all the typical cases of System-of-Interest related to software are listed here? No! The world is extremely diverse, there are innumerable different types of System-of-Interest, new business models appear every day, new types of System-of-Interest appear with these business models. The physical world is changing in a more and more sophisticated way, and systems thinking allows you not to get confused in this sea of definitions and pay attention to the main thing: what is changing in the physical world, what is the system realization, what is the goal of the whole big (not just your small part) project, what people will agree to pay for.

All this reasoning is easily transferable from the world of algorithms to the world of data. Forty years ago there were not even personal computers (the first appeared in 1980), and twenty years ago it was still thought that the world would be taken over by complex algorithms that would cunningly process relatively simple data in databases. Today it turns out that modern software is shifting toward working with simple algorithms on complex data. As complexity shifts from algorithms to data, the systems approach is becoming of interest not only to software engineers but also to data engineers. We should never forget that data are ultimately definitions of some systems, but the moment they are processed by some program, they themselves become part of that program’s system, they change their state, they can disappear, they behave like a “thing”. That is, the data for processing by a program must also be “made” from primary definitions. And when we are interested in how to get useful results from data, then, as in the case of programs, we must learn how to make them from raw data—and we, by analogy with DevOps let’s talk about DataOps.

Systems thinking is thereby needed by both programmers and data scientists: because of the deepening division of labor, these are no longer the same thing, although they are significantly related. Systems thinking will help software engineers, data engineers, data center administrative engineers, and managers of all these multiple roles to negotiate among themselves, as well as with other enterprise employees and the customers for whom they work. Software systems (while program operation), data systems (while data operation) are all systems; systems thinking applies just as much in the world of software as it does in the world of hardware systems, or organizational systems. It is just necessary not to emphasize too much the programmer part, all the time remember the subordinate role of software and the primacy of the physical world—and then everything in the project will be fine.

What about the people who work with the programs? Very often the system realization that people who are interested in a project will be some part of the organization that has to do some work—issue a loan, accrue a salary, make a part/pieca. And if it turns out that the program works correctly, but the people in the organization can’t work with it, then the work of the program won’t be counted as correct either. What good is a payroll program if people can’t work with it? If programmers want to get paid for their part of the work, they need to be sure that someone is working with people as well, and the customer will receive a joint system of people and programs (as well as data for this program, which can be a separate problem and may require separate performers). First, the accrued salary, manufactured quality part will be counted as a result; then the work of the unit leading to these essential results will do, and after that within that unit work, the software results.

Roughly the same reasoning that you do about computer programs can be done for training people. Books, videos are only definitions of what one would like to get after training. The purpose of training is a part of the human brain operation that turns on at the moment it enters the target environment (by analogy to a computer program) and performs the computation/thinking that the training was intended to do. The brain is a calculating machine, and the books read and videos watched only give a definition of what will be required of the brain in terms of the physical process (with changes of states!) of thinking in it in accordance with the results of training.

The only thing is that we do not need to talk about neurons and their learning, this is clearly not the level of detail that is discussed in learning. But representing the result of learning as a part of the brain trained to work under the target conditions makes us think both about what this learning looks like in the physical world (the brain part must be located somewhere at the moment of learning!) and about how the work of the result of learning as a system looks like in the physical world: there must be a corresponding physical environment. For example, at this moment a person may be in a machine shop, amidst the terrible rattle of the surrounding machines. Will the trained part of the brain turn on without an additional reminder? Will it produce, without error or omission, the thinking that it has been taught in that environment? How long will it take? What happens before that point, what will happen after that point? Going to the physical system (the part of the brain that is ready to act/think) turns out to be productive for the learning situation as well. There are many definitions in learning, but they are not the main thing. The main thing here is the resulting physical object with its prescribed properties.

What is the System-of-Interest for the bridge project? The bridge, of course! But to build a bridge, you have to create an organization that will design it, then create an organization that will deploy the construction of the bridge, then conduct the work of that construction organization (several thousand people in an open field!), and only then get the pleasure of the bridge. It’s all a long chain of enabling systems. And if they are so long in the case of simple physical systems like the bridge, in the case of software, they can be significantly longer. Imagine, for example, any of the programming projects, of which there are many as part of building a bridge. Why do they exist? Why this whole software thing? So that eventually there is a bridge! Here is systems thinking that requires tracing the entire chain from the software used in the construction project to the bridge itself. And if it turns out that the software doesn’t help bridge anyhow, then it will mean that this software does not need to be written at all.

Systems thinking will check that you are not doing unnecessary work. Systems thinking makes you think about it all at the beginning, not at the moment of non-signing of acceptance certificates for a “software creation” project. Usually nobody needs the software itself, they are only needed as parts of some other system—and you have to make sure that the development of these other systems as a whole goes first, and programs are only parts of these systems or parts of the systems that make these System-of-Interest—you have to deal with all the chains that lead to reality, to the physical world. Don’t confuse the photograph and the object depicted in the photograph, the book and the living world described in the book, the software and the real world described and changed by the software.

*There is a nuance here related to the von Neumann architecture: a program can be considered as data on a storage medium or an executable object. The same applies to “a program in the brain”: whether the brain in its neurons contains only a definition, or whether the neuronal network now specifically “calculates” something, i.e., a program-as-process is working in the physical world—this is the same question about “the materiality of thought”. But we are not considering these are nuances here. The advice here is to consider the probability with which we are talking about “just a documented definition of a program/thought” or “executing program/thought in the thinking process”, and to take this probability not from the “truth” but the goals of some action. And it is necessary to discuss the most probable case helpful in realizing what you have in mind. It is irrelevant in most cases. We remember that our systems thinking here is not mathematics with 100% formal statements that are poorly applicable to life, but rather probabilistic reasoning, “like in life”.

**An excerpt from Systems Thinking course

1 лайк