SofSW: The SW Basics (3/6)

The gate is quiet. There’s nobody standing behind the desk yet. The monitor above it reads my flight details. No other plane is using this gate before mine. The benches nearby are almost empty. There’s a girl lying on her back with her head against her backpack two rows ahead of me. She has her eyes closed and is taking long deep breaths. Clearly she’s asleep. A man is curled on his side on the next bench row reserving three benches at once. The fetal position seems comfortable and the blissfully peaceful look on his face confirms my thought. He’s in a better place.

I sit down as far away from the sleepers as I possibly can. I don’t want to disturb them, nor do I want to be disturbed right now. I need to straighten my thoughts and focus.

Let’s go back to the beginning. In order to make some useful predictions and formulas to enable non-intuitive deductions and inductions the foundation of the science has to solid rock. I can guide my intuition with a simple example. I have two software programs. They both do the same things. They were developed by two teams for the same purpose. They could be anything, like two identical word processors or spread-sheet programs or traffic light control programs or programs for operating a microwave oven. No matter how the programs were developed, they exist. They contain identical feature sets. They can both accomplish all tasks the other one can. What can we say about them intuitively?

Intuitively, if the two programs, program A and program B perform the same tasks, we can say that the sizes of their feature sets are the same. A feature set is the group of functions or tasks a program performs. We could call it the total functionality of the program. Functionality or features are the external effects the program can have. They are the output (in the widest possible sense) of the program. The features are measurable from from the outside. Features and functionality are without the program. Without an effect on its environment, the program has no meaning. If a feature can’t be measured or tested, it doesn’t exist. It’s as simple as that. Whatever a program can influence in its environment belongs to its feature set. External effects of a program are its output.

Let’s be more specific about this. If the (total) output of program A, let’s call it OA is the same as the output of program B (OB) then both programs perform the same functions and we can say that the outputs are identical. But we know intuitively that the implementations of the two programs can not be identical. The programs were developed in isolation and for any non-trivial program, there are almost infinite number of possible ways of implementation. The two teams could have used different programming languages, which would certainly make it certain that the implementations aren’t identical. This adds the concept of input into our scientific worldview of software. We’ll use IA for the input of program A and IB for the input of program B. The input can at this stage be anything. What I have in mind has something to do with the source code, the tangible input, but I’m sure the definition of input has to include resource files, possibly the tools used to generate the program and therefore also the environment has an effect. It isn’t clear at the moment, whether the software developers are part of the input or not. There is Ignorance about the details must not stop us now, though.

If both inputs and outputs were identical (IA = IB AND OA = OB), we are looking at the same program in both cases. The programs are identical. But this is no conclusion at all. What we want is to be able to compare two different programs. The outputs and inputs have two sides to them, perhaps we could call them dimensions even. In physics, in order to model the three-dimensional world we all live in, they use vectors. Vectors are useful little buggers, because they contain more information than just a magnitude like scalar values. Vectors also have a direction. The length of a vector shows its size, and sometimes that’s enough. I’m sure both input and output have many dimensions, and they would be best described as vectors, but can’t we do anything without the dimensions? Sure let’s just take the magnitudes and see what kind of conclusions we can draw. To get the magnitude of a vector, we’ll use vertical lines around the vector. Velocity is a vector, and its magnitude is speed. My train did reach a maximum speed of 125 km/h but to express velocity I’d have to add that it was heading east. In other words the maximum speed of the train, the magnitude of its maximum velocity (vmax) would be expressed: |vmax| = 125 km/h.

Let’s take any two programs, program A and program B. This time they don’t have to do the same things, this time we might be comparing a word processor to a microwave oven control software. If the sizes of the inputs of both programs are identical, but program A has a larger feature set (|IA| = |IB| AND |OA| > |OB|) then we can say that the density of program A is larger than the density of program B. In other words, program A accomplishes more with less.

On the other hand, if the outputs are identical in size but program A uses less input (|IA| < |IB| AND |OA| = |OB|), once again its density is higher than that of program B. This seems intuitive. Density is, without worrying about the units or possible coefficients, proportional to the ratio of output to input. In physics the Greek letter ϱ [rho] stands for density and proportionality is shown with this symbol ∝. To say that density is proportional to the ratio of output and input, we’ll just write:

ϱ ∝ O / I

Density is a scalar, it has no direction. I should have used the magnitudes of input and output because they are vectors, but I left the vertical lines out for clarity.

The density of an object in the real world is defined as the ratio between its mass and its volume.

ϱ = m / V

From this we could draw the conclusion that the mass and output of a program are proportional to each other and the input stands for the volume of the program. This is intellectually pleasing and intuitively correct, but we can’t put in any units or numbers just yet. For now we’ll have to settle for the conclusion that the mass is proportional to the size of the output of a program:

m ∝ |Osw|

and that the volume of the program is proportional to the size of its input:

V ∝ |Isw|

That’s it. There’s no need for a “mental-mass”. I can just use the mass as is to denote the external effects a program can have. Mass is linked with the concept of weight in the real world and it seems fairly reasonable to say that the more you can achieve with a program or application, the more weight it has. You can talk of real heavyweights, at least metaphorically, when you’re talking about the big and powerful applications. Small utility programs have small but specialized feature sets and it’s not disparaging to call them lightweights.