Smart

Innovative

Creative

Visionary

Ground-Breaking

Clever

Ingenious

Resourceful

Inherent complexity

• Arises from the problem domain
  • Part of the requirements for a system
• Cannot be eliminated easily
  • Only by reconsidering requirements

Artificially added complexity

• Added by DevSecOps teams
  • Intentionally or unintentionally
• Different reasons 
  • Design decisions
  • Implementation choices
  • Anticipation of future requirements
  • Habits
  • Adopting "best practices"

Keep it simple

• Avoid artificially added complexity
  • ⚠️ Anticipating vague, future requirements
  • Prioritize features driving inherent complexity correctly
• Question every component of your software architecture
  • If you cannot answer the "why?" question, YAGNI!
  • Do you really test and use what you built?
• Don't let aiming for "perfection" get in your way
  • Iterative development rules!
• Avoid fragmentation
  • Loosely coupling has its advantages, but also its downsides
  • Ask "why" again and be critical about vague answers

Avoid toil

• Regular, manual work are an alarm signal
  • Eliminate or automate
  • Have a focus on maintenance efforts
• Use managed services
  • Serverless or SaaS if possible
  • PaaS when finer control is required
  • ⚠️ Avoid IaaS and custom container images
• Automate to eliminate toil
  • ⚠️ Avoid over-automation
  • Focus on real, not potential toil
• Use alerts and automated anomaly detection

Using what many others are using

• Standing on the shoulders of giants
  • Battle-tested services/libraries
  • Available documentation and learning resources
  • AIs know a lot about the technology
• Adjust architecture to what's available (PaaS)
  • Use niche solutions only if really necessary
  • Consider cost-driven design
• Beware of abandoned services/frameworks/libraries
  • Prefer widely used, established services/frameworks/libraries
• ⚠️ Question "best practices" that add a lot of complexity
  • Do they offer enough added value to justify complexity?

Lock-in Effect

• Simple, integrated solutions are often cloud vendor-specific
  • Simplicity vs. lock-in
• Avoid investing in portable code if portability isn't a requirement
  • Change code when moving becomes necessary
  • Consider using abstractions in code to isolate dependencies
  • Make additional costs for building portable solutions visible
• ⚠️ Missing innovative solutions by always following the same path?
  • Strategies for bursting ones "bubble" are required (more later)

Security requirements raise the complexity 

• Reducing complexity can enhance security
  • Free resources can be invested in security
  • Fewer components lead to smaller attack surface
  • Simple architectures are easier to understand and maintain
• Complex systems become insecure under time pressure
  • Developers struggle and take shortcuts
• Externally imposed security requirements
  • Use built-in security mechanisms as much as possible
  • ⚠️ Established practices might not translate well

Personal preferences, beliefs, and habits 

• People want to follow their preferences and beliefs
  • You want people to take responsibility
• Simplification sometimes requires fundamental changes
  • Value of simplification vs. costs of changing status quo
• Gain flexibility to try things with a Microservice approach 
  • ⚠️ Loosely coupled components raise complexity
  • Don't let technology landscape diverge too much
• Lead by example

Value simple, stable solutions

• Make the importance of simplicity a shared value
  • Showcase not just innovative, complex solutions
  • Celebrate simple solutions with high developer productivity
• Don't punish accidental over-simplification
  • It is ok to re-introduce complexity after having removed it
• Don't punish complexity reduction
  • It is ok to admit mistakes
• Value stability
  • Leading-edge vs. "bleading" edge
  • ⚠️ But: Avoid letting components get outdated

Focus on the customer

• Customers want features, not self-purposed, fancy tech
  • Focus is added value from the customer's viewpoint
• Implement regular feedback and retrospectives
  • Involve customers
• Make hidden maintenance costs visible
  • How much time do we spend adding value vs. keeping system up?
• ⚠️ But: Demand clear and concrete requirements
  • Unclear requirements lead to over-engineering
  • Flexibility and config options have to be a requirement

Repeat what's working

• If something works, stick to it
  • ⚠️ Don't let conformity prevent innovation
• Make working solutions sharable and repeatable
  • Be very specific about responsibilities and maintenance
  • ⚠️ Prefer copying code over immature services/libraries
• Make small steps to improve patterns, practices, and principles
  • Continuous improvement
  • Continuous updates

Break out of the bubble

• Collaborate with others
  • Inside/outside of the organization
• Listen to newcomers
  • ⚠️ Value existing knowledge and experience of colleagues 
• Regular prototypes/studies of new tech/approaches
  • Company-specific "technology radar"

Allow new approaches

• Distinguish between prototypes/feasibility studies and production code
  • ⚠️ Never put prototypes into production
• Time/effort-boxed approach
  • E.g. Hackathons
  • E.g. Isolated, low-risk experiments
  • Benchmark early against existing patterns, practices, and principles
  • ⚠️ Avoid the sunk cost fallacy
• Stay appreciative regarding legacy code
  • Legacy code is code that earns money
  • Have a path forward for legacy code to avoid obsolescence