Any process can be described by several different "correct" command sequences. A hundred programmers would be able to write a hundred different payroll programs, each of which would perform what is required of it. A small number among them would be optimal. Important features of each program sometimes conflict with each other, just as in the design of aircraft sizes conflict with speed. After reading chapter 5, you will learn that each program has at least 12 characteristics and some of them, when embodied in one program, may conflict with others. The multitude of possible solutions is a major obstacle to properly managing the software development process.

Abstract nature of software. None of the five human senses can feel a large software system. It is abstract. You can see and feel a computing machine worth $20 million or a bridge worth $100 million. As the number of commands in a program increases, it becomes more and more difficult to see.

Looking at a list of a million lines of commands is not as easy as looking at the bridge. It is impossible to see neither the sequence of execution of commands nor the structure of the program. You can only see a thick pack of paper, strings of different characters, but not software. This property of the software makes managing its development very difficult.

The main tool for creating new software is the calculating machine and its software. Software developers in their work use the computer and software as the main tool to form and create new programs. The software is a "tool for making tools" in such usage.

The software can be considered either as an executor of the task (period of use), or as an assistant in creating new additional software (development period). These roles are completely different, and the fact that the same hardware can be used to perform both functions is a source of extreme amazement for many newcomers.

For those who work with computers and software all the time, this fact is so obvious that they think it goes without saying. They are not confused by the fact that in one sentence they discuss, say, VAX-11 as a performer of the operating system that controls the flight of the missile, and in the next sentence they go on to discuss the work of the same physical machine located in the same place, working in the same configuration, but already in the role of a "tool" machine, which is used to accompany programs performed at the time when VAX-11 controls the flight of the missile.

For people who are far from this kind of development, such a narrative may seem vague, since the text mixes sentences telling about two completely different ways of using the same machine.

This dual role should be clearly highlighted. Professional programmers should switch from describing one machine role to describing the other with care, making sure to include such switches.

The difficulty of software development often lies not in the functions it performs, but in the way it interacts with the user. Requirements for system reliability often make development much more difficult than the function that the software should perform. It is easy to make a program that controls the flight of an aircraft. It is very difficult to ensure that this program never stops working, despite the hardware and software failures and errors of the pilots. Still, the interaction factors are often left out of the developers' sight or misunderstood by them. Developing self-healing programs is one of the most difficult things to do.

Some types of software can be developed using the same methods as the hardware, while others cannot be developed the same way. The software consists of individual commands, and we can write commands to do almost anything, and in a lot of different ways. A command is not a physical "thing". Hardware, however, is a physically real thing, so you cannot rearrange and combine it so freely. We highlight those individual cases where programs become similar to hardware and must be developed using the same methods. However, in large systems, hardware and programs have significant differences. Hardware can be compared here with a piano and software with music. Hardware is a dictionary and software is a novel. So, despite the large number of similar in the hardware and programs, in the development of large systems in the foreground stands their fundamental difference. In more detail this question will be considered further.

Correct software is not subject to any failures. It therefore does not need any maintenance. Such a process should not be called maintenance but an ongoing development. If the commands are written correctly, they cannot suddenly become wrong. They may become obsolete, but this happens for other reasons. They can also be wrong from the beginning, which was not detected in the tests. The maintenance of a program, in other words an ongoing development, consists in detecting previously undetected errors, adding new functions, modifying some functions, improving performance.

This fact is extremely important! Many programmers think that maintenance is not an interesting thing and not as prestigious as program development. However, ongoing development is often more complicated than the original development. We should call it more accurately - it is ongoing development - and thus contribute to removing the embarrassing and undeserved stain on those involved in maintenance.

Software development is a multifaceted activity, not just about running on a computer. When working on a large software system project, you usually need to be competent in both general engineering and mathematics, you need to know different types of weapons, know the laws of celestial mechanics, know military logistics, know the methods of economic planning, understand what is redundancy, you need to navigate in the theory of interplanetary flight and aerodynamics, as well as in a huge number of different areas of knowledge. The head of software development should take all this into account in his project. It means that this manager must have the ability to manage a group of specialists from different fields.

A large software system can never be fully debugged, even after years of testing and use. Only small programs can be debugged to the end, but large and complex ones cannot. Too many paths provide a common program algorithm, too many possible variants of input data or user actions.

Even hundreds of years of ongoing testing - if, of course, it were possible - would not be enough to check all possible branches of a large, complex program. And despite this, there are people who are seriously talking about "error free software"!

Software development is often a very laborious and expensive process. In the United States, over $20 billion is invested in software development every year. This is a lot, and there is a steady upward trend in such contributions. And not all investments pay off.

In the early 1970s, two major airlines filed lawsuits against their contractors, because the system they created, worth $40 million, not only did not work, but did not show any signs of life at all. A large European bank filed a lawsuit to recover $70 million paid for the software. The U.S. Air Force spent more than $300 million in a futile attempt to automate an integrated transportation and supply system.

Software is a means, not a goal. One of the great technical teams works for the National Security Agency (NSA). It specializes in cipher security and unraveling, and recruits and educates experts in various technological methods.

Recently, a computer and communications guy told me about events that happened a few years ago when he was chairman of the Standards Committee for Acquired Software.

One of his committee members, a terrible bore, constantly insisted that the top-down method, very popular among software developers, should be used in their committee. This meant that they should not hold meetings on the software until they had discussed the systems for which the software was needed and of which it should become a part.

Finally, the chairman had to go to the head of the NSA and tell him that the member in question was right - first the committee had to develop standards and guidelines for purchasing systems, and then move on to the software.

Although the head of NSA felt that they knew how to acquire systems, the first document issued by the committee was a document entitled "Policy on System Acquisition". Only then was it possible to move on to the software!

Software is a "third order" product, it helps the whole system to work and the system is already achieving the desired results.

Software itself can never be considered as an end product. Even as a marketable product, it has an auxiliary character and must be designed and sold with this in mind.

What do we mean by "third order"? The first place is definitely the desired result. For example, the increase in ticket sales that has occurred due to the introduction of the pre-order system. The result is what we strive for, it is the goal of paramount importance. In the background is the system that achieves this result, and software, as part of this system, takes only the third place. The important thing, that's right. Maybe the most important, but still only the third.

Why focus on this obvious fact? Winston Churchill defined a fanatic as a person who does not change his decision and does not translate the conversation into another subject. We are constantly faced with "programmer-fanatics", who believe that nothing is more important than software. These fanatics cannot be trusted to lead systems or projects, because they have a distorted view of the world around them and a twisted view of the software, the system and the result.

Defining the requirements is the most underdeveloped area related to software creation. This area is not just about software; it is about all kinds of hardware, people, and technology! If software is seen as an auxiliary mechanism, the resulting products will be much better than if it is considered the primary and most important factor.