The Invisible Art: Truly Understand Software Development!

Slide 1

Slide 1 text

The Invisible Art: Truly Understand Software Development! Eberhard Wolff Head of Architecture https://swaglab.rocks/ https://ewolff.com/

Slide 2

Slide 2 text

Why “The Invisible Art”? •We are not building physical things. •So we are fundamentally different. •Or are we?

Slide 3

Slide 3 text

Anyone Else Creating “Invisible” Things? •Books •Movies •Music •Also collaborative •So is software development is art?

Slide 4

Slide 4 text

So what are we actually doing?

Slide 5

Slide 5 text

What Are We Actually Doing? •We are building software e.g. to support business processes. •Not in scope of this talk: Building Infrastructure software (frameworks, databases etc.)

Slide 6

Slide 6 text

Reality Mental Model Software This insurance costs 10€ per month. Understand how to calculate the cost. Code to calculate the cost.

Slide 7

Slide 7 text

Reality Mental Model Software This insurance costs 10€ per month. Understand how to calculate the cost. Code to calculate the cost. Code becomes reality!

Slide 8

Slide 8 text

Reality Mental Model Software This insurance costs 10€ per month. Understand how to calculate the cost. Code to calculate the cost.

Slide 9

Slide 9 text

Where is the Bottleneck?

Slide 10

Slide 10 text

Reality Mental Model Software This insurance costs 10€ per month. Understand how to calculate the cost. Code to calculate the cost. Philosophy Learning Understanding

Slide 11

Slide 11 text

We Learn not just about Reality! Mental Model Reality / Domain Architecture Techniques Technologies New Requirements

Slide 12

Slide 12 text

Software development = learning

Slide 13

Slide 13 text

So?

Slide 14

Slide 14 text

Actually, this means software development is different from many other activities.

Slide 15

Slide 15 text

Software Development = Learning •You can’t really speed up learning. •A new developer will need to learn the domain. …i.e. they will be quite slow at the beginning, …and slow the team down due to teaching. •Still people try to add developers to speed things up.

Slide 16

Slide 16 text

The Mythical Man-Month (Frederick P. Brooks, 1975)

Slide 17

Slide 17 text

Software Development = Learning •Hand over is costly •Developers are not easy to exchange. •Maintenance teams: good idea?

Slide 18

Slide 18 text

Software Development = Learning •The important thing to learn is the domain. •Domain-driven design is crucial! •Still development is considered a technical job!

Slide 19

Slide 19 text

Software Development = Learning •You can’t understand everything correctly all at once! •There will be misconceptions. •So we will make “mistakes”! •Still blame people for making mistakes!

Slide 20

Slide 20 text

https://software-architektur.tv/2023/12/08/folge191.html

Slide 21

Slide 21 text

Get Rid of Misconceptions •Feedback shows misconception. •Build something new based on learning. •Iterations! •Still waterfall is considered a valid approach. •Still architecture is supposed to be future-proof.

Slide 22

Slide 22 text

https://software-architektur.tv/2022/05/13/folge119.html

Slide 23

Slide 23 text

https://www.heise.de/blog/Wasserfall-Modell-LOL-4878614.html

Slide 24

Slide 24 text

https://software-architektur.tv/2022/10/28/folge140.html

Slide 25

Slide 25 text

Development Organization Reality / domain Learns in iterations Architecture techniques New requirements Technologies

Slide 26

Slide 26 text

Domain / User Discovers new possibilities Reflects about software, business, marketplace I.e. new requirements Learns in iterations

Slide 27

Slide 27 text

Software Changes in iterations

Slide 28

Slide 28 text

Development Organization Domain / User Software

Slide 29

Slide 29 text

Development Organization Domain / User Software All of them change!

Slide 30

Slide 30 text

Development Organization Domain / User Software Influences

Slide 31

Slide 31 text

Sociotechnical Systems •Software + the people building it •Origin: Study of coal mining in England, Word War II •Mining: very mechanical •Software: deals with logic and data •If “sociotechnical system” is useful to think about mining, how much more useful is it for software?

Slide 32

Slide 32 text

We must think about software & humans!

Slide 33

Slide 33 text

https://software-architektur.tv/2021/07/09/folge66.html

Slide 34

Slide 34 text

Development Organization Domain / User Software ? ? ? Are you looking for a deterministic, easy to follow set of rules for this?

Slide 35

Slide 35 text

Development Organization Domain / User Software ? ? ? Try it out and see what happens. Sorry.

Slide 36

Slide 36 text

Feedback

Slide 37

Slide 37 text

Development Organization Domain / User Software Feedback all over the place! Feedback must be voiced. Feedback must be taken into account.

Slide 38

Slide 38 text

This is culture. This is hard to change.

Slide 39

Slide 39 text

Is there any way to systematically improve feedback?

Slide 40

Slide 40 text

Tenerife Aircraft Crash •Deadliest aircraft disaster •Two Jumbo Boeing 747 collided on the ground •Extremely senior crews •Including a KLM “rockstar” •583 dead, 61 survivors https://creativecommons.org/publicdomain/zero/1.0/deed.en

Slide 41

Slide 41 text

Tenerife Aircraft Crash • Crashes have many reasons. • Fog • No ground radar • Airport closed -> diversion of flights • Problems in communication • Taxing on runway • But: KLM pilot took off without clearance …and the rest of the crew did not intervene https://en.wikipedia.org/wiki/Tenerife_airport_disaster https://creativecommons.org/publicdomain/zero/1.0/deed.en

Slide 42

Slide 42 text

https://software-architektur.tv/2023/08/11/folge178.html

Slide 43

Slide 43 text

Air Crashes: Lessons Learned •Tenerife is just one example of a pattern. •Investing in safer technology only takes you so far.

Slide 44

Slide 44 text

Air Crashes: Lessons Learned •Collaboration matters! •Even if the goal is very clear: i.e. arrive at destination safely. •How much more if the goal is to satisfy stakeholders …who learn about the domain themselves.

Slide 45

Slide 45 text

Air Crashes: Lessons Learned •Air crashes are about your life. •Software is usually “only” about money. •Air crews fail to collaborate when it’s about their life. •Why do we expect software teams to collaborate successfully?

Slide 46

Slide 46 text

Air Crashes: Lessons Learned •Crews make seemingly trivial mistakes. •Crew members do not intervene. •Even though it is their job. •Even though the lives of the crew are on the line. •Software teams have not so clear roles. •Why should they successfully mention problems and solve them?

Slide 47

Slide 47 text

No blame for errors is not enough!

Slide 48

Slide 48 text

“Everyone can say whatever they like!” is not enough!

Slide 49

Slide 49 text

Is there any way to systematically improve feedback?

Slide 50

Slide 50 text

Crew Resource Management •Use every resource to the fullest! •Resources: humans and technical tools. •This is about making air travel even safer. •This is not about making everyone happy. •Software project sometimes seem to confuse happy and successful.

Slide 51

Slide 51 text

Crew Resource Management & Architecture •Use the expertise of the full crew! •The only thing the captains decides by themselves is to abort a take-off. •Who should we involve in decisions? •How are e.g. juniors involved?

Slide 52

Slide 52 text

Crew Resource Management & Architecture •Enable communication! •Treat (junior) people so that they speak up. •Smile, be gentle etc •Because you want to fully utilize them! •Do we even care in software projects? •Sometimes aggressive communication is rewarded.

Slide 53

Slide 53 text

Crew Resource Management & Architecture •CRM is part of the pilot training •…and part of exercises in the simulator. •I.e. feedback on the interactions of the crew. •How do we train software teams? •Where is feedback provided on interactions? •Retros? •Scrum master?

Slide 54

Slide 54 text

Crew Resource Management & Architecture •Investigation never stops at “That person was stupid!” •Rather “What made that person behave that way?” •Consider Training •Consider situation •What happened before the flight? •How do we deal if an individual seems to fail?

Slide 55

Slide 55 text

https://software-architektur.tv/2022/11/04/folge141.html

Slide 56

Slide 56 text

https://software-architektur.tv/2023/10/27/folge187.html

Slide 57

Slide 57 text

Is Software Engineering really so different?

Slide 58

Slide 58 text

What if we build a bridge the way we build software?

Slide 59

Slide 59 text

What If Software Engineers Build a Bridge? Actually, software engineering is a lot more complex. The bridge would be a disaster.

Slide 60

Slide 60 text

Is Software Engineering Engineering?

Slide 61

Slide 61 text

Has anyone here engineered a bridge?

Slide 62

Slide 62 text

Do you think anyone outside our industry would believe how it really works?

Slide 63

Slide 63 text

Is Software Engineering Engineering? •Hillel Wayne interviewed “crossovers”. •I.e. software engineers that used to be engineers in other fields •Consensus: Software engineering is engineering

Slide 64

Slide 64 text

Is Software Engineering Engineering? •All engineering aims at iteration. •But the price of an iteration is different. •But: crossovers’ advice: plan more upfront (?)

Slide 65

Slide 65 text

Porsche 959

Slide 66

Slide 66 text

Porsche 959

Slide 67

Slide 67 text

https://software-architektur.tv/2024/03/27/folge209.html

Slide 68

Slide 68 text

Is Software Engineering Engineering? •Software Engineering is more “open” •Sharing knowledge •E.g. conferences

Slide 69

Slide 69 text

Conclusion

Slide 70

Slide 70 text

Conclusion •Software development is no art! •Software development is a lot about learning. •We must work in iterations! •Software are sociotechnical systems. •We should learn from other industries! •We are not so different from other engineering disciplines.

Slide 71

Slide 71 text

Send email to [email protected] Slides + Sample Microservices Book DE / EN + Sample Practical Microservices DE/EN + Sample of Continuous Delivery Book DE Powered by Amazon Lambda & Microservices EMail address logged for 14 days, wrong addressed emails handled manually

Slide 72

Slide 72 text

Du hast noch Fragen oder möchtest dich mit mir austauschen? Komm gerne in der Netzwerklounge auf mich zu! [email protected] Austausch.