Gergő Pintér, PhD
gergo.pinter@uni-corvinus.hu
week | date | lecture | practical class |
---|---|---|---|
1 | 2025-09-17 | intro, software architecture | project assignment |
2 | 2025-09-24 | SDLC, scrum, kanban | project workshop |
3 | 2025-10-01 | requirement analysis, user story mapping | project workshop |
4 | 2025-10-08 | UML, C4 | project workshop |
5 | 2025-10-15 | design patterns | project workshop |
6 | 2025-10-22 | interfaces, implementation planning | req. analysis demo |
7 | 2025-10-29 | school holiday | |
8 | 2025-11-05 | wireframing, clean clode | project workshop |
9 | 2025-11-12 | code quality, code review | project workshop |
10 | 2025-11-19 | testing, legacy code | project workshop |
11 | 2025-11-26 | CI, automatization, devops | project workshop |
12 | 2025-12-03 | summary, course feedback | project workshop |
13 | 2025-12-10 | midterm | design demo |
14 | 2025-12-17 | no planned lecture |
week | date | lecture | practical class |
---|---|---|---|
1 | 2025-09-17 | intro, software architecture | project assignment |
2 | 2025-09-24 | SDLC, scrum, kanban | project workshop |
3 | 2025-10-01 | requirement analysis, user story mapping | project workshop |
4 | 2025-10-08 | UML, C4 | project workshop |
5 | 2025-10-15 | design patterns | project workshop |
6 | 2025-10-22 | interfaces, implementation planning | req. analysis demo |
7 | 2025-10-29 | school holiday |
week | date | lecture | practical class |
---|---|---|---|
8 | 2025-11-05 | wireframing, clean clode | project workshop |
9 | 2025-11-12 | code quality, code review | project workshop |
10 | 2025-11-19 | testing, legacy code | project workshop |
11 | 2025-11-26 | CI, automatization, devops | project workshop |
12 | 2025-12-03 | summary, course feedback | project workshop |
13 | 2025-12-10 | midterm | design demo |
14 | 2025-12-17 | no planned lecture |
requirements analysis (35%) + design (35%) + midterm (30%)
score (%) | grade |
---|---|
0-50 | 1 |
51-66 | 2 |
67-76 | 3 |
77-86 | 4 |
87-100 | 5 |
A computer program is a sequence or set of instructions in a programming language for a computer to execute. It is one component of software, which also includes documentation and other intangible components.
ISO/IEC 2382:2015 via Wikipedia [1]
There is a metaphor saying that a program is like a recipe.
The computer follows the instructions of a program as the cook follows the instruction in a recipe.
Consequently programming is like creating a recipe.
maintenance?
a software does not have to obey the laws of physics
based on Software Architecture Metaphors by Lisa Stähli [2]
Software rot (or software entropy) is the degradation, deterioration, or loss of the use or performance of software over time [3].
dormant rot: the software in question is not changed, but as the environment evolves, it eventually becomes dysfunctional
Muni metro’s control software is still loaded from floppy disks [4]
active rot
based on Software Architecture Metaphors by Lisa Stähli [2]
based on Software Architecture Metaphors by Lisa Stähli [2]
software is often measured by the source lines of code
app | version | LOC (million) |
---|---|---|
Vanilla Music Player for Android | 1.3.2 | 0.048 |
VLC for Android | 3.6.5 | 0.265 |
Telegram for Android (messaging app) | 11.14.1 | 6.6 |
GCC (compiler) | 15.1 | 15 |
Firefox (web browser) | 142 | 45 |
Windows [5] | 10 | 50 |
Linux (kernel) | 6.16 | 40 |
further read about size of software by Christopher McFadden
number of lines of code is increasing
infographic about codebase growth
because we want
more and more functionality
24 million lines of code – operational and support – needed for the F-35 to be fully operational; when the program started, the estimated number of lines of code required was closer to 15 million
– Robert N. Charette, F-35 Program Continues to Struggle with Software [6]
source: www.folklore.org by Andy Hertzfeld | CC-BY-NC
Quickdraw: 2D graphics library
if we wish to count lines of code, we should not regard them as “lines produced” but as “lines spent”
E. W. Dijkstra EWD 1036
Every line of code written comes at a price: maintenance. To avoid paying for a lot of code, we build reusable software. The problem with code re-use is that it gets in the way of changing your mind later on.
We don’t add stuff “just because we can”. We need to have a damn good reason for it.
A designer knows he has achieved perfection not when there is nothing left to add, but when there is nothing left to take away.
– Antoine de Saint-Exupéry (29 June 1900 – 31 July 1944)
Linux Torvalds: despite not really having any single thing that stands out… 5.8 looks to be one of our biggest releases of all time
a more technical read: Why Linux’s biggest ever kernel release is really no big deal
based on Simon Mutch’s Version Control materials
In practice, everything that has been created manually should be put in version control, including programs, original field observations, and the source files for papers.
– Best Practices for Scientific Computing; Wilson et al. 2012 (arXiv:1210.0530)
this presentation is under version control as well
The current level of software complexity is not manageable without allowing many people to work on the same code base, and the separation of the development versions from the production one.
later on the course: the types and operation of version control systems
if you want to deliver product fast, and the developer time is expensive, reuse components
is it possible to decrease the dependency stack?
There are known knowns; there are things we know we know. We also know there are known unknowns; that is to say we know there are some things we do not know. But there are also unknown unknowns – there are things we do not know we don’t know.
– Donald Rumsfeld (13th & 21st United States Secretary of Defense)
complexity class | known | unknown | knowns | unknowns |
---|---|---|---|---|
simple | ✓ | x | ✓ | x |
complicated | ✓ | x | ✓ | ✓ |
complex | x | ✓ | ✓ | x |
chaotic | x | ✓ | x | ✓ |
source: [12]
from Michael Bykovski’s essay [12]
Stacey matrix [14]
“Architecture” is a term that lots of people try to define, with little agreement. There are two common elements: One is the highest-level breakdown of a system into its parts; the other, decisions that are hard to change.
– Martin Fowler - Patterns of Enterprise Application Architecture
In most successful software projects, the expert developers working on that project have a shared understanding of the system design. This shared understanding is called ‘architecture’. This understanding includes how the system is divided into components and how the components interact through interfaces. These components are usually composed of smaller components, but the architecture only includes the components and interfaces that are understood by all the developers.
Ralph Johnson, XP mailing list
All architecture is design but not all design is architecture. Architecture represents the significant design decisions that shape a system, where significant is measured by cost of change.
– Grady Booch
# Title
## Status
What is the status, such as proposed, accepted,
rejected, deprecated, superseded, etc.?
## Context
What is the issue that we're seeing that is
motivating this decision or change?
## Decision
What is the change that we're proposing and/or doing?
## Consequences
What becomes easier or more difficult to do
because of this change?
ADR template by Michael Nygard from Documenting architecture decisions
topologies, for example
based on: Introduction to Software Architecture
Architecture is the decisions that you wish you could get right early in a project.
– Ralph Johnson
to do that, you need to know all the unknowns, so you need requirements analysis, and learning the new/unknown technology