The Invisible Art: Truly Understand Software Development!

Software development is one of the most complicated activities of mankind - and you can't even touch the result.
That's why software development stands out from all other human activities and that has consequences. This talk is about these special properties, why nobody should take the waterfall model seriously, why requirements have to change, and why the error culture is so crucial for successful development.

Transcript

1. The Invisible Art: Truly Understand Software Development! Eberhard Wolff Head of Architecture https://swaglab.rocks/ https://ewolff.com/
2. Why “The Invisible Art”? •We are not building physical things. •So we are fundamentally different. •Or are we?
3. Anyone Else Creating “Invisible” Things? •Books •Movies •Music •Also collaborative •So is software development is art?
4. So what are we actually doing?
5. 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.)
6. Reality Mental Model Software This insurance costs 10€ per month. Understand how to calculate the cost. Code to calculate the cost.
7. Reality Mental Model Software This insurance costs 10€ per month. Understand how to calculate the cost. Code to calculate the cost. Code becomes reality!
8. Reality Mental Model Software This insurance costs 10€ per month. Understand how to calculate the cost. Code to calculate the cost.
9. Where is the Bottleneck?
10. Reality Mental Model Software This insurance costs 10€ per month. Understand how to calculate the cost. Code to calculate the cost. Philosophy Learning Understanding
11. We Learn not just about Reality! Mental Model Reality / Domain Architecture Techniques Technologies New Requirements
12. Software development = learning
13. So?
14. Actually, this means software development is different from many other activities.
15. 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.
16. The Mythical Man-Month (Frederick P. Brooks, 1975)
17. Software Development = Learning •Hand over is costly •Developers are not easy to exchange. •Maintenance teams: good idea?
18. Software Development = Learning •The important thing to learn is the domain. •Domain-driven design is crucial! •Still development is considered a technical job!
19. 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!
20. https://software-architektur.tv/2023/12/08/folge191.html
21. 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.
22. https://software-architektur.tv/2022/05/13/folge119.html
23. https://www.heise.de/blog/Wasserfall-Modell-LOL-4878614.html
24. https://software-architektur.tv/2022/10/28/folge140.html
25. Development Organization Reality / domain Learns in iterations Architecture techniques New requirements Technologies
26. Domain / User Discovers new possibilities Reflects about software, business, marketplace I.e. new requirements Learns in iterations
27. Software Changes in iterations
28. Development Organization Domain / User Software
29. Development Organization Domain / User Software All of them change!
30. Development Organization Domain / User Software Influences
31. 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?
32. We must think about software & humans!
33. https://software-architektur.tv/2021/07/09/folge66.html
34. Development Organization Domain / User Software ? ? ? Are you looking for a deterministic, easy to follow set of rules for this?
35. Development Organization Domain / User Software ? ? ? Try it out and see what happens. Sorry.
36. Feedback
37. Development Organization Domain / User Software Feedback all over the place! Feedback must be voiced. Feedback must be taken into account.
38. This is culture. This is hard to change.
39. Is there any way to systematically improve feedback?
40. 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
41. 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
42. https://software-architektur.tv/2023/08/11/folge178.html
43. Air Crashes: Lessons Learned •Tenerife is just one example of a pattern. •Investing in safer technology only takes you so far.
44. 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.
45. 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?
46. 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?
47. No blame for errors is not enough!
48. “Everyone can say whatever they like!” is not enough!
49. Is there any way to systematically improve feedback?
50. 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.
51. 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?
52. 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.
53. 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?
54. 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?
55. https://software-architektur.tv/2022/11/04/folge141.html
56. https://software-architektur.tv/2023/10/27/folge187.html
57. Is Software Engineering really so different?
58. What if we build a bridge the way we build software?
59. What If Software Engineers Build a Bridge? Actually, software engineering is a lot more complex. The bridge would be a disaster.
60. Is Software Engineering Engineering?
61. Has anyone here engineered a bridge?
62. Do you think anyone outside our industry would believe how it really works?
63. 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
64. Is Software Engineering Engineering? •All engineering aims at iteration. •But the price of an iteration is different. •But: crossovers’ advice: plan more upfront (?)
65. Porsche 959
66. Porsche 959
67. https://software-architektur.tv/2024/03/27/folge209.html
68. Is Software Engineering Engineering? •Software Engineering is more “open” •Sharing knowledge •E.g. conferences
69. Conclusion
70. 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.
71. Send email to devday2024@ewolff.com 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
72. Du hast noch Fragen oder möchtest dich mit mir austauschen? Komm gerne in der Netzwerklounge auf mich zu! devday2024@ewolff.com Austausch.