November 20, 2009

QCon 2009: Sustainable Design for Agile

(or "Quick and Sustainable Development of Complex Software")

Eric Evans

"We should do a nice design, but we just don't have the time"

  • Indicates the value you place, you'd never hear "We'd like to make money, but we just don't have the time."
    • "Modeling and design take extra time, but they pay off in the the long run" (excuse)

What is your goal?

  • Implement user story? Design will slow this down (this is where agile focuses)
  • Complete releasable set of stories with acceptable bugs? (here, modeling and design pay off)
  • Deliver release that can be extended to next one? (modeling and design pay off here, big time)
  • Deliver a clear and cohesive user experience? (again, pay off big time); being too feature driven can undermine this
  • Deliver something that advances the business strategy? (choosing features is more tactical)

Design advocates have a lot to answer for, lot of failures

XP: "No BDUF, YAGNI, we'll refactor"

  • EE involved in such projects: there was design going on, along with refusal to accept sloppy code
  • "Do the simplest thing that could possibly work" misinterpreted as "quickest" but "simplest" actually implies a lot of work


  • domain: sphere of knowledge or activity
  • model: system of abstractions; we typically think of UML, but... it's a visual representation of a program
    • distilled form of domain knowledge, rules, assumptions and choices

When are models useful?

  • when complexity of project in understanding and communicating about domain; not simple CRUD...
  • being selective of modeling work is critical

Why modeling has not advanced, misconceptions

  • Myth: Drive design from model ==> upfront analysis; WRONG: time you know the least about a project is in the beginning; upfront analysis is a way of locking in your ignorance

DDD + Agile

  • Technical solutions can distract us
  • Feature-orientation can fragment model
  • Up front analysis locks in ignorance

    • So iterations feed understanding into projects
  • Myth: Need tools that let us express models without getting bogged down in detail => need tools that allow less skilled developers to use parts created by smarties; WRONG: developers need to leverage design, not use it to replace thinking

  • Myth: Need tools to raise level of abstraction from programming => visual programming, UML extensions; WRONG: language is our fundamental abstraction tool, including when we create model; language starts with talking, fits great with Agile; every time you talk to your customer you're learning the domain

Favorite modeling tools:

  • Whiteboard
  • xUnit: intent to express domain in code (not necessarily executable)
  • Mouths and ears

(video: s/w expert and domain expert collaborate)

Domain expert is changing the software expert's view of the domain and model, changing an assumption as to when the state can be realized (balance of acct vs balance according to contract).

DDD can be undramatic

  • Walking through concrete reference scenario (users like focusing on these)
  • Creative collaboration
  • Refinement of ubiquitous language and therefore model

Another video with software driven process (vs customer), feature driven

  • What's a "special case"?
  • "Special case" means our model doesn't accommodate; too many of these means we need to adjust
  • software-focused modeling, agile => focused on green bar! just get the feature working
  • (from video) "I guess you'd get the right answer that way"
    • red flag that user doesn't agree with model, or doesn't understand
  • On projects when there's dissonance we say "We'll fix that later", but we never do
    • Example of video with "dummy payment" or "fake principal" because our assumption is that someting MUST exist in a particular place

"If we must have violent water-based metaphors, I do a whirlpool rather than a waterfall."

(Domain Language Model Exploration Process -- diagram and explanation from draft of paper.)

A few highlights from this:

  • tell stories, then explore; some users are better about this than others, but they'll all tell you something useful, even in what they elide
  • exploration process; code probe, proposing scenarios, proposing models, talk talk talk
  • emphasize: must be able to make mistakes; in fact he stresses that people need to come up with at least three bad ideas when exploring with domain expert -- "most creative ideas are bad ideas, at least at first"

Toward end:

  • idea you never look ahead beyond the next story is damaging; not using your assets; some people are good at seting how the little piece fits into the big picture -- let them!

CMW: You need to iterate your learning about the domain just as you iterate your learning about the implementation. (Probably more.)

Next: QCon 2009: Architecture
Previous: QCon 2009: SOA at eBay