Architectural Clash - HalfStack Meetup March 2019

The purpose of the talk is to introduce a new format designed to tackle legacy code and technical debt. This format is called Architectural Clash. We will analyze the principle behind the format and some successful use case in which this format really helped our team to deliver value to an existing codebase.

Transcript

1. Architectural Clash
2. Francesco Strazzullo (AKA Strazz) - francesco.strazzullo@flowing.it - https://github.com/francesco-strazzullo - https://twitter.com/@TheStrazz86 - https://www.francescostrazzullo.info/video - https://medium.com/@TheStrazz86 Ego Slide
3. http://frameworklessmovement.org/
4. WE DEVELOP DIGITAL PROJECT TOGETHER WITH YOU.
5. Which project do you prefer? Photo by Loren Gu on Unsplash Photo by Valeriy Kryukov on Unsplash
6. Legacy Code
7. Valuable Code that everyone Hates
8. How do we try to tackle legacy code?
10. Photo by Levi Guzman on Unsplash
11. Photo by George Bonev on Unsplash
12. Who do we blame when a refactoring process fails?
15. “Programming is a social activity” Robert C. Martin
16. Introducing Architectural Clash
17. Architectural Clash is a two day workshop that helps team to define a Roadmap
18. Principles
19. Start with why
21. Learn By Doing
22. Kaizen
23. Majo statt Senf [CC BY-SA 4.0 (https://creativecommons.org/licenses/by-sa/4.0)] Kai Zen
24. Continuous Improvement with small steps
26. Vestibulum congue tempus Sense Making Clash Decide
27. Phase 1: Sense Making
28. Duration: ~4 hours People Involved: Management, Tech Team and Stakeholders
29. Explore the context of your software
30. Try to write a list of business needs and prioritize it
31. ➔ Less bugs in production ➔ Increase Velocity for new features ➔ Easy Onboarding ➔ Easier Recruitment ➔ Don’t miss the deadline Examples of Business Needs
32. Yes, but how to write this list?
33. ➔ Retrospective ➔ Lean Value Tree ➔ Impact Mapping ➔ SWOT Analysis ➔ Tradeoff Slider ➔ Lego Serious Play Exercises
34. From the business needs try to extract a list of experiments that will increase the code quality
35. ➔ Extract the core domain to a separate micro service ➔ Automate the build with CI ➔ Remove AngularJS and use Web Components for the frontend ➔ Remove Tomcat and use Spring Boot for our JVM application Example of Experiments
36. Business needs should be the Why behind technical decisions
37. Phase 2: Clash
39. Duration: ~8 hours People Involved: Tech Team
40. Learn from Code
41. Bring all your tech team together and bring someone that doesn’t know the code at all
42. Split the group in very small teams (two or three people) and work on different experiments for 45 minutes
43. At the end of the 45 minutes bring all the team together to exchange the results for 15 minutes
44. Every team should write an outcome answering these questions and put it on the wall • What did we do? • What did we learned? • Did we encounter any roadblock?
45. Repeat until the time ends
46. Remember that the purpose of the experiment is to learn, not to solve the problem
47. Phase 3: Decide
48. Duration: ~4 hours People Involved: Management and Tech Team
49. From every outcome, try to extract an action and put them on an Change Options Canvas
51. Create your refactoring roadmap
52. Repeat the Architectural Clash after six months
53. Vestibulum congue tempus Why How What
54. Frequently Asked Questions
55. What happens if in 45 minutes I’m not able to learn anything on the problem?
56. I can’t convince the management to be part of this workshop. Is this a problem?
57. How do people feel after this kind of workshop?
58. Is there any material if I want to prepare this workshop for my company?
59. Thanks! Francesco Strazzullo francesco.strazzullo@flowing.it