Recommended
Recommended
More Related Content
Similar to By Thoughtworks | Reviving the art of software design with Andy Marks and Pam Rucinque
Similar to By Thoughtworks | Reviving the art of software design with Andy Marks and Pam Rucinque (20)
Recently uploaded
Recently uploaded (20)
By Thoughtworks | Reviving the art of software design with Andy Marks and Pam Rucinque
- 1. © 2022 Thoughtworks | Confidential By Thoughtworks 1
- 2. © 2022 Thoughtworks | Confidential By Thoughtworks Reviving the art of software design 2
- 3. Is the single biggest contributor to your organisation's codebases?
- 4. "the quick brown fox jumps over the lazy dog"
- 5. export function isPangram(sentence) { return new Set(sentence .toLowerCase() .replace(/[^a-z]/g, '') ).size === 26 "the quick brown fox jumps over the lazy dog" Pangram.isPangram( ) // => true
- 6. wwthere are reasonsww design is still important w we are responsible w change starts small we're bad at design
- 7. Why we care (including obligatory awkward audience participation)
- 12. Distributed systems design is complex Monolithic Service-oriented Microservices Serverless
- 13. Distributed systems design is complex Monolithic Service-oriented Microservices Serverless Inside the box design
- 14. Distributed systems design is complex Monolithic Service-oriented Microservices Serverless Inside the box design Outside the box design
- 15. Distributed systems design is complex Monolithic Service-oriented Microservices Serverless Inside the box design Outside the box design Why we care
- 16. How did we end up here?
- 17. Larger toolsets make mastery harder How did we end up here
- 18. Larger toolsets make mastery harder How did we end up here Source: cncf.io
- 19. Larger toolsets make mastery harder How did we end up here Source: cncf.io
- 20. Monolithic Service-oriented Microservices Serverless “Less code” led to less attention to design How did we end up here
- 21. Monolithic Service-oriented Microservices Serverless “Less code” led to less attention to design average codebase size ↓ How did we end up here
- 22. Outsourcing of design atrophied our skills How did we end up here
- 23. Outsourcing of design atrophied our skills How did we end up here
- 24. Outsourcing of design atrophied our skills How did we end up here
- 25. Outsourcing of design atrophied our skills How did we end up here
- 26. Outsourcing of design atrophied our skills How did we end up here
- 27. Startup mindsets normalised breaking things How did we end up here
- 28. Startup mindsets normalised breaking things How did we end up here
- 29. What can we do? ● "Less code" led to less attention to design ● Outsourcing of design atrophied our skills ● Larger toolsets make mastery harder ● Startup mindsets normalised breaking things
- 30. To afford (more) time for design... What can we do
- 31. Don't be a feature factory What can we do
- 32. To allow us to focus on fewer tools... What can we do
- 33. Constrain technology options What can we do
- 34. To raise awareness around good software design ... What can we do
- 35. Rediscover the classics What can we do
- 36. To embed knowledge using practical experience ... What can we do
- 37. Practice with intent exercism.io freeCodeCamp.org leetcode.com rosettacode.org architecturalkatas.com What can we do
- 38. To know if the correct design decisions are being made... What can we do
- 39. Verify your design describe "Observability" do it "streams metrics" do expect(service.has_metrics()).to be(true) end it "has parseable logs" do expect(service.has_logs()).to be(true) end end Credit: https://www.thoughtworks.com/en-au/insights/articles/fitness-function-driven-development What can we do with fitness functions
- 40. Summary
- 41. Good design saves time Distributed systems design is complex Why we care How did we end up here? What we can do? Constrain technology options Rediscover the classics Don't be a feature factory Verify your design Practice with intent In summary... “Less code” led to less attention to design Outsourcing of design atrophied our skills Larger codebases make mastery harder Startup mindsets made us break things
- 42. “Make it work, Make it right, Make it fast” - Kent Beck
Editor's Notes
- List of pangrams -> https://clagnut.com/blog/2380/
- Tornhill, A, Borg, MCode Red: The Business Impact of Code Quality - a Quantitative Study of 39 Proprietary Production Codebases. In Proceedings of the International Conference on Technical Debt 2022 (pp. 11–20). Association for Computing Machinery. @inproceedings{10.1145/3524843.3528091, author = {Tornhill, Adam and Borg, Markus}, title = {Code Red: The Business Impact of Code Quality - a Quantitative Study of 39 Proprietary Production Codebases}, year = {2022}, isbn = {9781450393041}, publisher = {Association for Computing Machinery}, address = {New York, NY, USA}, url = {https://doi.org/10.1145/3524843.3528091}, doi = {10.1145/3524843.3528091}, abstract = {Code quality remains an abstract concept that fails to get traction at the business level. Consequently, software companies keep trading code quality for time-to-market and new features. The resulting technical debt is estimated to waste up to 42% of developers' time. At the same time, there is a global shortage of software developers, meaning that developer productivity is key to software businesses. Our overall mission is to make code quality a business concern, not just a technical aspect. Our first goal is to understand how code quality impacts 1) the number of reported defects, 2) the time to resolve issues, and 3) the predictability of resolving issues on time. We analyze 39 proprietary production codebases from a variety of domains using the CodeScene tool based on a combination of source code analysis, version-control mining, and issue information from Jira. By analyzing activity in 30,737 files, we find that low quality code contains 15 times more defects than high quality code. Furthermore, resolving issues in low quality code takes on average 124% more time in development. Finally, we report that issue resolutions in low quality code involve higher uncertainty manifested as 9 times longer maximum cycle times. This study provides evidence that code quality cannot be dismissed as a technical concern. With 15 times fewer defects, twice the development speed, and substantially more predictable issue resolution times, the business advantage of high quality code should be unmistakably clear.}, booktitle = {Proceedings of the International Conference on Technical Debt}, pages = {11–20}, numpages = {10}, keywords = {developer productivity, code quality, technical debt, software defects, business impact, mining software repositories}, location = {Pittsburgh, Pennsylvania}, series = {TechDebt '22} }
- Our industry has moved towards distributed systems designing for distributed systems is hard, extra considerations engineers earlier in their careers are making decisions that were exclusive to more experienced developers or architects. In a monolithic architecture, all the layers of a feature live inside the box Some outside the box decisions Surface area of software design has shrunk, architecture surface area has expanded. More outside the box design decisions to make, more people involved Design mistakes are going to happen, we’re human. that’s how we learn but A mistake in a distributed architecture, is a distributed mistake, harder to diagnose and rectify
- Our industry has moved towards distributed systems designing for distributed systems is hard, extra considerations engineers earlier in their careers are making decisions that were exclusive to more experienced developers or architects. In a monolithic architecture, all the layers of a feature live inside the box Some outside the box decisions Surface area of software design has shrunk, architecture surface area has expanded. More outside the box design decisions to make, more people involved Design mistakes are going to happen, we’re human. that’s how we learn but A mistake in a distributed architecture, is a distributed mistake, harder to diagnose and rectify
- Our industry has moved towards distributed systems designing for distributed systems is hard, extra considerations engineers earlier in their careers are making decisions that were exclusive to more experienced developers or architects. In a monolithic architecture, all the layers of a feature live inside the box Some outside the box decisions Surface area of software design has shrunk, architecture surface area has expanded. More outside the box design decisions to make, more people involved Design mistakes are going to happen, we’re human. that’s how we learn but A mistake in a distributed architecture, is a distributed mistake, harder to diagnose and rectify
- Our industry has moved towards distributed systems designing for distributed systems is hard, extra considerations engineers earlier in their careers are making decisions that were exclusive to more experienced developers or architects. In a monolithic architecture, all the layers of a feature live inside the box Some outside the box decisions Surface area of software design has shrunk, architecture surface area has expanded. More outside the box design decisions to make, more people involved Design mistakes are going to happen, we’re human. that’s how we learn but A mistake in a distributed architecture, is a distributed mistake, harder to diagnose and rectify
- It’s not negligence, laziness Industry wide, systemic problems There are perfectly valid reasons. "Accelerated expectations around delivery strangling tech consolidation"
- Know too much about too much Description of the pic In contrast, the tools I needed to know when I started were four maybe five Devs Stretched too thin, No mastery or enough knowledge of what make it right means New things come up No time
- Know too much about too much Description of the pic In contrast, the tools I needed to know when I started were four maybe five Devs Stretched too thin, No mastery or enough knowledge of what make it right means New things come up No time
- Know too much about too much Description of the pic In contrast, the tools I needed to know when I started were four maybe five Devs Stretched too thin, No mastery or enough knowledge of what make it right means New things come up No time
- Codebase has shrunk Tricked into thinking less code, less design Code has just dispersed to more codebases. We still have to connect components, with low coupling.
- Codebase has shrunk Tricked into thinking less code, less design Code has just dispersed to more codebases. We still have to connect components, with low coupling.
- The way we address software design as individuals has changed We used to rely exclusively on patterns and principles that we learnt from reading books But now, we outsource design decisions to tools, and in most cases we’re being responsible. trade off we’re not flexing our design muscles, paying someone to go to the gym for us. There are still decisions to make, how good will they be if we dont practice often? AWS Codewhisperer beta just launched
- The way we address software design as individuals has changed We used to rely exclusively on patterns and principles that we learnt from reading books But now, we outsource design decisions to tools, and in most cases we’re being responsible. trade off we’re not flexing our design muscles, paying someone to go to the gym for us. There are still decisions to make, how good will they be if we dont practice often? AWS Codewhisperer beta just launched
- The way we address software design as individuals has changed We used to rely exclusively on patterns and principles that we learnt from reading books But now, we outsource design decisions to tools, and in most cases we’re being responsible. trade off we’re not flexing our design muscles, paying someone to go to the gym for us. There are still decisions to make, how good will they be if we dont practice often? AWS Codewhisperer beta just launched
- The way we address software design as individuals has changed We used to rely exclusively on patterns and principles that we learnt from reading books But now, we outsource design decisions to tools, and in most cases we’re being responsible. trade off we’re not flexing our design muscles, paying someone to go to the gym for us. There are still decisions to make, how good will they be if we dont practice often? AWS Codewhisperer beta just launched
- The way we address software design as individuals has changed We used to rely exclusively on patterns and principles that we learnt from reading books But now, we outsource design decisions to tools, and in most cases we’re being responsible. trade off we’re not flexing our design muscles, paying someone to go to the gym for us. There are still decisions to make, how good will they be if we dont practice often? AWS Codewhisperer beta just launched
- we normalised trading off internal software quality, with good design for speed of delivery. Luckily for us technologists, technology is no longer an afterthought. It is quite the opposite, a super competitive market that has left businesses in constant fear of disruption or any other existential threat. Business are pushed to innovate, serve their customers in however many channels possible (mobile, web, voice, your watch) and that has created a massive amount of work that has to be delivered NOW. And our industry reacted to that improving its delivery cadence, deployments are faster now with cloud providers, testing is automated but that hasn’t been enough,so we also started trading off time to design because time to market is more important That was particularly reinforced by Mark Z with FB’s motto “move fast and break things” famous, and everyone started emulating it But it does not work, to the point that At the 2014’s F8 developer's conference, Mark Zuckerberg jokingly rolled out a new motto for Facebook: "Move Fast With Stable Infra." But the mindset was already in the wild and is still is.
- we normalised trading off internal software quality, with good design for speed of delivery. Luckily for us technologists, technology is no longer an afterthought. It is quite the opposite, a super competitive market that has left businesses in constant fear of disruption or any other existential threat. Business are pushed to innovate, serve their customers in however many channels possible (mobile, web, voice, your watch) and that has created a massive amount of work that has to be delivered NOW. And our industry reacted to that improving its delivery cadence, deployments are faster now with cloud providers, testing is automated but that hasn’t been enough,so we also started trading off time to design because time to market is more important That was particularly reinforced by Mark Z with FB’s motto “move fast and break things” famous, and everyone started emulating it But it does not work, to the point that At the 2014’s F8 developer's conference, Mark Zuckerberg jokingly rolled out a new motto for Facebook: "Move Fast With Stable Infra." But the mindset was already in the wild and is still is.
- Our Common Future, also known as the Brundtland Report, was published on October 1987 by the United Nations through the Oxford University Press. This publication was in recognition of Gro Harlem Brundtland's, former Norwegian Prime Minister, role as Chair of the World Commission on Environment and Development.Wikipedia
- Like testing functionality Fitness functions Manual, automatic checks Inside the box: linters, cognitive complexity Outside the box: is your system observable, scalable, etc
- Good design means we can change our software confidently and quickly We now live in a distributed world where mistakes are widely distributed too. At an organisational level Ways of working, prioritising time At a team level for prioritising how to use your time
- This Kent Beck quote has been the mantra of my career.. I think we have a decision to make: We build software that just works but mos likely have to rewrite in a couple of years because it’s too hard to change, or we spend the time and effort now building well designed software that can evolve with the product?