Upgrade to Pro — share decks privately, control downloads, hide ads and more …

The Invisible Art: Truly Understand Software De...

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.

Eberhard Wolff

April 16, 2024
Tweet

More Decks by Eberhard Wolff

Other Decks in Technology

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. 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.)
  4. Reality Mental Model Software This insurance costs 10€ per month.

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

    Understand how to calculate the cost. Code to calculate the cost. Code becomes reality!
  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. Philosophy Learning Understanding
  8. We Learn not just about Reality! Mental Model Reality /

    Domain Architecture Techniques Technologies New Requirements
  9. So?

  10. 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.
  11. Software Development = Learning •Hand over is costly •Developers are

    not easy to exchange. •Maintenance teams: good idea?
  12. Software Development = Learning •The important thing to learn is

    the domain. •Domain-driven design is crucial! •Still development is considered a technical job!
  13. 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!
  14. 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.
  15. Domain / User Discovers new possibilities Reflects about software, business,

    marketplace I.e. new requirements Learns in iterations
  16. 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?
  17. Development Organization Domain / User Software ? ? ? Are

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

    it out and see what happens. Sorry.
  19. Development Organization Domain / User Software Feedback all over the

    place! Feedback must be voiced. Feedback must be taken into account.
  20. 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
  21. 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
  22. Air Crashes: Lessons Learned •Tenerife is just one example of

    a pattern. •Investing in safer technology only takes you so far.
  23. 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.
  24. 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?
  25. 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?
  26. 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.
  27. 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?
  28. 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.
  29. 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?
  30. 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?
  31. What If Software Engineers Build a Bridge? Actually, software engineering

    is a lot more complex. The bridge would be a disaster.
  32. 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
  33. Is Software Engineering Engineering? •All engineering aims at iteration. •But

    the price of an iteration is different. •But: crossovers’ advice: plan more upfront (?)
  34. 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.
  35. 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
  36. Du hast noch Fragen oder möchtest dich mit mir austauschen?

    Komm gerne in der Netzwerklounge auf mich zu! [email protected] Austausch.