Software as Engineering in Constraints

PROGRESS

The idea of progress, as a linear progression has often led us astray into thinking, that complexity somehow correlates to development. Faster Machines means a more complex architecture, faster software means more layer and complex design. Progress, in this imagination, is measured by the distance between what we can presently accomplish and what we might eventually accomplish without obstruction.

ENGINEERING

This manner of looking at engineering, especially in the context of software, can make us blind to the fact, that the first step of engineering is to understand the science, to discover the constraints under which, something has to be designed, and we are not always presented with the conditions for the design a-priori, and guessing can lead to some hot mess, that we often see in the software industry presently. Web pages of hundreds of megabytes, apps eating 3-4 GB RAM just to render, simple GUI pages and programming languages introducing layer and layer of abstraction to do the most simplest thing one could achieve by using a loop.

SOFTWARE ENGINEERING

So, software in this regard takes a special space, It's apparent immateriality can be deceptive. Unlike a bridge or an engine, a program does not seem to possess an obvious material form whose limitations are immediately legible. Its structures are logical, its components abstract, and its possibilities seemingly inexhaustible. But the moment software encounters the world, this apparent freedom begins to contract. Computation consumes time and memory, communication introduces latency and requirements contradict within themselves. Thus, the idea of software engineering is hardly one of resource allocation alone, although in some sense, one can reduce everything to that, but it is one of having better abstractions and a more mature sense of the idea of optimization, so as to make optimizations not entail itself in terms of improvements in abstract, but specifically attempts to answer the concrete question of, what is this optimization for and what would be its consequences beyond its locality of improvements. A general goal sounds ideal, and is ideal, but in real-world, generalizations or unification of software have only lead to unnecessary baggage, for which systems neither should have cargo to carry nor the goodwill. Architecture, therefore, moves beyond, just elegance, and presents itself, as a manipulation of theory, or instantiated variations of theory in action, in particular with peculiarities of the subject system, not a solution in general.

Efficiency, reliability, security, accessibility, and maintainability cannot always be maximised simultaneously, and the decision to privilege one over another cannot be settled by technical competence alone, thus, the question now remains no longer exclusively technical. It is one which reflects our biases and priorities as individuals and perhaps also as a society.

Software engineering, understood this way, is neither the pursuit of a world without constraints nor the passive acceptance of those that happen to exist. It is the sustained exercise of distinguishing what must be accepted from what can be changed, what should be optimised from what should be preserved, and what appears possible from what can be made reliable, intelligible, and worth maintaining. Software that respects the constraints, and not wassailed by the advancements in hardware to simply not care about its cost, seems to be the way to go.

SOFTWARE AS ENGINEERING IN CONSTRAINTS

Perhaps the better form of engineering competence is the real-time realization of the things we have chosen not to do. To engineer well, then, is not merely to make the possible actual. It is to understand the boundaries of possibility in the natural world, with all its constraints, mechanical, computational, economic, social, or psychological, respected; and to exercise sound judgement within them.

BIBLIOGRAPHY

A. Core sources — software engineering and design

1. Simon, H. A. (1996). The sciences of the artificial (3rd ed.). MIT Press. https://mitpress.mit.edu/9780262691918/the-sciences-of-the-artificial/
2. Brooks, F. P., Jr. (1987). No silver bullet: Essence and accidents of software engineering. Computer, 20(4), 10–19. https://doi.org/10.1109/MC.1987.1663532
3. Parnas, D. L. (1972). On the criteria to be used in decomposing systems into modules. Communications of the ACM, 15(12), 1053–1058. https://doi.org/10.1145/361598.361623
4. Brooks, F. P., Jr. (1995). The mythical man-month: Essays on software engineering (Anniversary ed.). Addison-Wesley.
5. Dijkstra, E. W. (1989). On the cruelty of really teaching computing science. Communications of the ACM, 32(12), 1398–1404. https://doi.org/10.1145/76380.76381

B. Philosophy of technology and the social implications of design

1. Heidegger, M. (1977). The question concerning technology. In The question concerning technology, and other essays (W. Lovitt, Trans. & Intro.). Harper & Row. (Original essay published 1954.)
2. Winner, L. (1980). Do artifacts have politics? Daedalus, 109(1), 121–136. https://www.jstor.org/stable/20024652

C. History and philosophy of science

1. Carnot, S. (1824). Réflexions sur la puissance motrice du feu et sur les machines propres à développer cette puissance [Reflections on the motive power of fire and on machines fitted to develop that power]. Bachelier.