DRAFT - Last updated 2025-12-02

Software Engineering

One of my software engineering teachers back at the polytechnic used to say that programming is about understanding and actually had that as a quote in the introduction to his book on usability. But another teacher said that software engineering isn’t real engineering because there’s no math involved.

But is it true that there’s no math involved? The doubting Thomas of a teacher in question from what I know was an electronics engineer and probably was simply ignorant of the various mathematical aspects of software engineering as the kind of math that is involved wasn’t really taught in that school at the time.

Yes, in traditional engineering fields like civil engineering or mechanical engineering there’s a lot of math involved in the design and analysis of structures and systems e.g., calculating loads, stresses, and material properties of bridges, engines, etc.

But software engineering also involves mathematical concepts and principles, though they may not always be as overtly visible as in traditional engineering fields. For example, algorithms and data structures are fundamental to computer science and software engineering, and are used to calculate very analogous things like time and space complexity of programs.

In software engineering you take for example from vendor specifications information about the performance of hardware components and use that to estimate how much load a system can handle in terms of concurrent users or transactions per second. How is that so different from calculating load and stress in a bridge or engine in order to ensure it can handle the expected forces with a sufficient safety margin?

Software engineering in my mind is about creating and maintaining software on an industrial scale as opposed to mere hobbyist coding of small scale projects. In this the whole lifecycle of the software is important including how the team is built and how work is organized for that entire span of time.

It’s not just about writing code. It’s about building an entire system that includes people, processes, tools, and the software itself with the software being in terms of competence management know-how in the form of an artifact of that system. As software is more malleable than traditional engineering artifacts like bridges or engines, as the building material is intangible (code, data), the people designing it are the builders as well as the architects of that system and often also the maintainers of it over time with it being the unfortunate case that the original builders are often not available for maintenance later with lots of the knowledge about the system lost over time and the people often having less training and experience in maintaining complex software systems and in general the software engineering discipline not being as mature as traditional engineering disciplines. Practically always the project is just as much about managing and developing the people and the processes as it is about the software itself.

It’s about managing complexity, ensuring quality, and delivering value to users over time. There are all kinds of principles and forces at play that need to be understood and managed in order to create successful software systems.

For the software itself there’s the requirements that need to be balanced with whatever real world constraints there are.

Laws, Forces, Principles and Heuristics

Brooks: Adding manpower to a late software project makes it later.

Conway: Any organization that designs a system will produce a design whose structure is a copy of the organization’s communication structure.

Little: The average number of items in a queuing system equals the average arrival rate multiplied by the average time an item spends in the system.

Metcalfe: The value of a telecommunications network is proportional to the square of the number of connected users of the system.

Wirth’s law: “Software is getting slower more rapidly than hardware becomes faster.”

Parkinson’s law: “Work expands so as to fill the time available for its completion.”

Hofstadter’s law: “It always takes longer than you expect, even when you take into account Hofstadter’s Law.”

Gall’s law: “A complex system that works is invariably found to have evolved from a simple system that worked.”

The Peter principle: “In a hierarchy every employee tends to rise to his level of incompetence.”

The Pareto principle: “For many events, roughly 80% of the effects come from 20% of the causes.”

Diminishing returns: “The more you optimize something, the less room there is for further optimization.”

Amdahl’s principle: “the overall performance improvement gained by optimizing a single part of a system is limited by the fraction of time that the improved part is actually used.”

Gustafsons law that states that “the speedup of a program using multiple processors in parallel computing is limited by the sequential fraction of the program.”