Simplify! 10 ways to reduce complexity in software development

This slide deck discusses options to reduce complexity in software development. It starts with a short rationale why complexity of IT systems has become a critical issue. It then discusses the difference between essential complexity (which we cannot reduce) and accidental complexity (which we should reduce) and states that the majority of IT system complexity is accidental complexity. Additionally, the slides briefly discuss how the ubiquitous fixation on efficiency reinforces the complexity problems.

The main part of the slide deck presents and discusses 10 basic ideas how to reduce complexity in software development – or to be more precise in the systems created during software development. The discussion of the 10 ideas does not provide fine-grained instructions as this would be way beyond the scope of this talk. Instead, it provides a different perspective on many widespread and "proven" practices that drive complexity and offers alternative approaches to address these topics.

As always, the voice track is missing. However, I still hope that these slides provide some food for thought and useful ideas.

Transcript

1. Simplify! 10 ways to reduce complexity in software development Uwe Friedrichsen – codecentric AG – 2020-2025
2. Uwe Friedrichsen Works @ codecentric https://bsky.app/profile/ufried.bsky.social https://www.speakerdeck.com/ufried https://ufried.com/simplify_intro/
3. Why should we simplify?
4. 1 IT has become indispensable
5. 2 We are drowning in complexity
6. What are we doing to improve the situation?
7. We add more complexity!
8. We are Wile E. Coyote just before looking down
9. We need to simplify!
10. Complexity needed to solve a given problem Complexity not needed to solve the problem essential complexity accidental complexity
11. < 20% > 80% essential complexity accidental complexity
12. Cannot be reduced Must be reduced essential complexity accidental complexity
13. Simplify! is about reducing accidental complexity
14. Drivers of accidental complexity
15. Levels Time then now Market Governance Project Technology Architecture Implementation IT landscape General Complexity drivers at the market level • Industrial setup for post-industrial markets (aim to reduce variance) • More investment planning and control • More project planning • More standardization • More guidelines and gateways • Less technology options • Decision makers not understanding what they decide about
16. Levels Time then now Market Governance Project Technology Architecture Implementation IT landscape General Complexity drivers at the governance level • Not understanding IT • Software development is design • Software must be changed to preserve its value • Invisibility makes software even harder to grasp • Not understanding the role of IT • IT not being a cost center anymore
17. Levels Time then now Market Governance Project Technology Architecture Implementation IT landscape General Complexity drivers at the project level (I) • Counter-productive budgeting and project staffing processes • Leading to bloated requirements • Leading to budgets considered lower bounds • Useless requirements due to an inward-bound focus • Neglecting uncertainty leading to many pointless requirements
18. Levels Time then now Market Governance Project Technology Architecture Implementation IT landscape General Complexity drivers at the project level (II) • “Agile” and “DevOps” cargo cults, not improving anything • Only business features create value • The “high utilization means more productivity” fallacy • Enterprise Architecture Management as an impediment (trying to “streamline” the application landscape) • Compliance/governance implemented wrong adding accidental complexity
19. Levels Time then now Market Governance Project Technology Architecture Implementation IT landscape General Complexity drivers at the technology level • FOMO as complexity driver • Stuck before the consolidation of the technology evolution cycle • Blindly copying “cool” concepts (e.g., from Hyperscalers)
20. Levels Time then now Market Governance Project Technology Architecture Implementation IT landscape General Complexity drivers at the architecture level • Unresolved design deficiencies (How to apply the foundations of design) • Black holes and strange attractors • Architecture Narcissism • Technology blinders (not understanding the problem domain) • DIY and OSS
21. Levels Time then now Market Governance Project Technology Architecture Implementation IT landscape General Complexity drivers at the implementation level • Breaking the existing designs • Implementation shortcuts • Design by Stack Overflow • Show-off implementation • Keystroke theater • Quality theater
22. Levels Time then now Market Governance Project Technology Architecture Implementation IT landscape General Complexity drivers at the IT landscape level • Missing responsiveness of IT • Fear of decommissioning old systems • Missing technology evolution • “No time to clean up” fallacy (urgent vs. important) • The big clean-up initiative
23. Levels Time then now Market Governance Project Technology Architecture Implementation IT landscape General General complexity drivers • Efficiency obsession & effectiveness neglect • Short-sighted thinking and acting • Missing feedback loops • Local optimizations • Collective continuous amnesia
24. Levels Time then now Market Governance Project Technology Architecture Implementation IT landscape General General complexity drivers • Efficiency obsession & effectiveness neglect • Short-sighted thinking and acting • Missing feedback loops • Local optimizations • Collective continuous amnesia
25. efficiency effectiveness
26. "Efficiency is the ability to do things well, successfully, and without waste.” — https://en.wikipedia.org/wiki/Efficiency
27. "Effectiveness is the capability of producing a desired result.” — https://en.wikipedia.org/wiki/Effectiveness
28. Effectiveness is about doing the right thing. Efficiency is about doing the thing right.
29. "It is far better to do the right thing wrong than to do the wrong thing right.” -- Russell L. Ackoff
30. "There is nothing worse than doing the wrong thing well.” -- Peter Drucker
31. efficiency effectiveness Focus on input/process/output Focus on outcome/impact
32. efficiency effectiveness Increases accidental complexity Reduces accidental complexity
33. Focusing on effectiveness (without neglecting efficiency) is a very powerful antidote to unbridled complexity creep
34. Let’s Simplify! 10 ways to reduce complexity
35. Goals of Simplify! Maximize effectiveness Minimize accidental complexity Optimize at all levels Optimize over time
36. 1Embrace uncertainty
37. Embrace uncertainty • Go for hypothesis-driven development • Create awareness if business value is not created
38. 2 Establish feedback loops
39. Establish feedback loops • Implement feedback loops across IT value chain • Connect decision makers to decision consequences • Alternatively create actual cross-functional teams • Abandon Agile and DevOps cargo cults • … or at least work around them • Go DevOps / "Product” / Team topologies / unFIX / ...
40. 3 Resist FOMO
41. Resist FOMO • Do not fall for hypes • Only go for new technology for problems you really have • Not an imagined problem or because others use it • Not for ”solving” non-tech problems • Only if not adopting it has a negative impact • Prefer boring technology
42. 4 Foster understandability
43. Foster understandability • Become egoless • Beware of architecture narcissism • Write understandable code • Consider effects over time and people • Learn 10 finger touch typing • Abandon keystroke theater
44. 5 Aim for powerful abstractions
45. Aim for powerful abstractions • Aim for simple and powerful abstractions • More complexity does not mean more powerful • Prefer deep modules * • Ensure easy integration • Learn the foundations of good design (and how to apply it) * see “A Philosophy of Software Design” by John Ousterhout
46. 6 Internalize architecture without an end state
47. Architecture without an end state • Prefer styles and principles over blueprints • Know when to move on • Use Wardley mapping • Calculate the price of doing nothing • Establish a continuous improvement process • Ponder construction for deconstruction • Keep the solution topical • Keep the size of systems in check
48. 7 Understand distributed systems
49. Understand distributed systems • Remote communication changes everything • Need to ensure deterministic behavior over a probabilistic communication channel • Only distribute a system if needed to meet quality goals • Dismiss reusability in distributed contexts • But embrace it in local contexts
50. 8 Keep code proliferation in check
51. Keep code proliferation in check • Avoid quick hacks and local “optimizations” • Use more than one pair of eyes • Code reviews • Pair programming • Mob/Ensemble programming • Implement regular “explain and train” sessions • Document design principles and coding practices
52. 9 Think global, act local
53. Think global, act local • Leave the comfy chair • Aim for holistic understanding • Learn about business, operations, etc. • Beware local optimizations • Abandon projects (if possible) • Projects maximize local thinking, ignoring global effects • Beware short-term efficiency thinking • E.g., avoid quick hacks to shed a few days in dev
54. 10 Mind the complexity bias
55. Mind the complexity bias • Beware the “cult of complex” • Apply Occam's razor
56. B1 Help people understand software
57. Help people understand software • Explain that business and IT have become inseparable • Explain that software must be changed to preserve its value • Stop hiding complexity • Do not oversimplify for people not proficient in IT • Use metaphors from the physical world • Helps people to overcome the invisibility barrier • But know (and explain) the limits of the metaphors
58. B2 Leverage the power of “why”
59. Leverage the power of “why” • Ask “why” • Do not be afraid to question complexity • Resist solving non-tech problems with technology • Be gentle, yet persistent
60. Wrap-up
61. Wrap-up • We need to simplify! • IT has become indispensable • We are drowning in complexity • Simplify! Is about reducing accidental complexity • Minimize accidental complexity • Maximize effectiveness • Optimize at all levels • Optimize over time
62. Remember …
63. Nobody wants to be Wile E. Coyote just before looking down
64. Where are you going to start?
65. Uwe Friedrichsen Works @ codecentric https://bsky.app/profile/ufried.bsky.social https://www.speakerdeck.com/ufried https://ufried.com/simplify_intro/