An interesting Evolutionary Design talk

I'm finally getting up to date with a non-trivial backlog of pending talks to watch, and today I watched one that resonated so much with me that I wanted to a) express how interesting it is and b) keep some notes about it in the blog, because it is so nicely explained.

If you like concepts like Test-Driven Development, the old Extreme Programming, or simply like to do true lean development and real iterative software building, I'm confident you will enjoy it. But I encourage everybody to watch it, even if you don't fully share the principles [1].

The talk is Evolutionary Design Animated, by James Shore, presented at YOW! 2019. Consists of two parts, each around 25 minutes: Part I, Part II

Notes:

Evolutionary design:

  1. Simple Design
  2. Continuous Design
  3. Reflective Design

All of them enabled by fast & reliable automated tests

Simple Design

  • Start with a walking skeleton
  • Do the simplest thing that could possibly work
  • You Aren't Gonna Need It
  • Simple, not sloppy

Rules for simple design:

"When, not if, I need to change this decision in the future, how hard will it be?"

  • Every concept once
  • ...And only once (don't repeat yourself)
  • Design intent clear and obvious
  • Concrete, not speculative
  • Cohesive: code that changes together, stays together
  • Decoupled: if it's out of sight, it's safely out of mind
  • Isolated: if it's widely used, it's abstracted by an interface

Continuous Design

  • Constantly review and improve the design
  • Merciless refactoring
  • Collective ownership
  • Pairing and/or mobbing
  • Continuous Integration
  • Camp site rule: Don't make it perfect; just make it better

Reflective Design

  • Review the code you're about to work on
  • Identify flaws ("code smells", difficulty understanding)
  • Reverse engineer design of code, if necessary
  • Imagine how to improve the design of the code
  • Incrementally refactor the code to reach desired design


[1] I disagree with the speaker's point of view regarding using existing open-source solutions vs building your own, as a DIY approach also can carry heavy maintenance burdens, and not all open-source software has high maintenance costs.

An interesting Evolutionary Design talk published @ . Author:

Comment