Software Engineering is a learning process, working code a side effect

I have come to the conclusion that Software Engineering is primarily a learning endeavour, the working code is rather a side effect.

This quote is actually not mine but I am paraphrasing Alberto Brandolini who is making this very point in Event Storming (he was actually talking about Software Development, but I do not want to get into an academic discussion on the differences between Software Engineering and Development and I am treating them as being equal here).

I have actually always been thinking of Software Engineering (SE) as a learning process, but it was only until I read Brandolinins Event Storming where I found this view expressed in such clarity, which also made it clear to me that I, myself have been seeing SE in this very way. In short: for any non-trivial SE project, the main challenge is understanding the domain, which is primarily a learning process. This view is also very prominent in the Domain-Driven Design community and was expressed by Eric Evans himself: The critical complexity of most software projects is in understanding the domain itself.

It is no surprise that agile processes have been proven to be so successful and useful: they emphasise collective learning. What is even better is that agile is a very scientific approach to SE: we fornulate hypotheses from discussions (among developers and customer) and then test them in experiments to arrive at new insights and deeper understanding. Plan-based processes on the other hand are a rather inductive aproach, based on many assumptions which are not tested and verified until the very end (just ask yourself: would you approach your Ph.D. in that way?)

When we finally acknowledge that SE is a learning process then we need to structure the methodologies, processes, tools and technologies around it to create an environment where quick, shared learning can happen through continuous experimentation and feedback:

  • Lightweight requirements allowing for quick understanding of the domain and what and why to implement for whom: Impact Maps (Godzic), Event Storming (Brandolini), User Stories, User Story Mapping (Patton).
  • A lightweight development and engineering process with emphasis on collective learning through continuous feedback: Agile / Scrum with eXtreme Programming (XP) practices.
  • A suitable design methodology which emphasises collective learning and experiments: Domain-Driven Design
  • The most suitable architecture for the problem at hand, found by applying careful prototyping.
  • A programming language which makes it easier to map the domain into code: object-oriented, something along Java, C#,… (I am actually going to do research on using Haskell for that, but that is a topic for another post)
  • Technology which lets developers focus on the learning of the domain instead of dealing with low-level plumbing: Spring, Thymeleaf, REST, React/Angular/Vue/…, Hibernate, Web, Mobile, IDEs,…

It is my firm belief that learning SE requires to apply it in the same way as learning a programming language requires us to apply it. Yes, when learning how to program we have books and slides and lecture notes describing the language and concepts but they always come with exercises. It is a mystery to me how we can write SE books which ignore that.

Unfortunately none of the SE textbooks I have read and studied (I had a fair share of them…) seems to embrace all of the above in any deeper way, and just throws a checklist of the usual topics at the reader in a rather very academic, dry and boring way. These books seem to treat SE simply as a collection of methodologies, processes, tools and technologies as a means to an end in itself which need to be applied somehow. A student who works through them has acquired lot of book knowledge about SE but has no clue how to really put it together and how the knowledge really relates to real-world SE. Even worse, the idea that SE is a learning process is not communicated in any of the SE textbooks I know. I think one of the main reason this is the case is that all these books have been written a long time ago and have only been extended with “newer” topics such as Agile / Web / Cloud / Whatever but have been sticking to the same end 90s/early 2000s SE mindset (just think about it: Sommerville is in its 10th edition now…),

Therefore, it is my aim to write a textbook book on applied, modern SE which is going to embrace all discussed issues above - I feel it is a very much needed textbook. It will be based on my teaching experience from my SE course at the FHV, paired with real-world experience from myself and industry partners. At the moment it is just a vision in my head but I want to get into it as soon as possible. Uunfortunately not before Spring 2022 as I will be occupied with a heavy load of teaching until then but this will give me enough time to earn more experience in teaching SE and reflecting my approach to the book which I will share in future posts.