December 2003
Notes 9, 4th Session
Guest Author: Eric Evans

Part III introduction

Robert: The 3 issues on p.188, the qualifications for doing
domain-driven development

(mention of OO databases)

Eric: [use of OO databases is rare] Because there aren’t so many people

using rich domain models.

Tracy: Isn’t there also a comfort level with relational databases?

Robert: And ad-hoc reporting, etc.

John B: This is discussed in Crossing The Chasm, etc. People only
change technologies at gunpoint, figuratively speaking. But when
there’s a shift, often the change is permanent (e.g. CodeWarrior
beating LightSpeed C).

Tim: Very few people believe the #2 issue, willingness to evolve and

change the model.

Eric: I really thought about this list very hard. People might have a

domain model, and the willingness to evolve and change it, but they
didn’t have the knowhow for #3, the design skills. Or sometimes they
would isolate the designers from the coders.

[some notes lost to editor program failure]

(question about deep models)?

Russ: We worked on an autodialer where we made effective use of a deep

model of the problem domain. The customer was happy to find out that
our solution had lots of areas of flexibility where they were able to

ask for new features that they had not thought of before.

Tracy: We had another project where we had solved a problem with
respect to arranging some resources in memory blocks. The customer
gave us a new variation of the problem where they thought it would be
a
difficult elaboration of the previous version.

Russ: But it fell out naturally from the solution of the specific
problem we had solved previously.

Jeff M: Was this a question of a “deep model” or more a question
of
solving a general case and being able to then handle specific cases
more easily?

Russ: It was specific to the problem domain, and their “difficult

elaboration” was one that made a lot of sense in terms of the original

problem.

Jeff M: Close in concept space, then.

Russ: Yes.

Eric: Once you’ve experienced it, it seems real. It’s the fact that
this occurs so rarely that is part of the reason I wrote this book.

(some additional discussion, mention of O-R mapping, “well-worn
glove”
metaphor of an effectively evolved domain model)

Chapter 8, Breakthrough

Eric: O-R mapping means you have to change a translation layer when you

change the model. It means you have to carry more along as you refine

the model, as you make changes to reflect deeper insights. Or when you

refactor away from a code smell. You still come to points where you
make a breakthrough, it’s just slower.

(show of thumbs, how many people have 1,”seen a deep model?”
2, had a
“breakthrough” from better understanding a model”)

Eric: Ah, interestingly more people have had the “breakthrough”

experience than the deep model.

Russ: Who broke through and didn’t get to a deep model?

Tim: In your own little parts which you have freedom to change, you can

have significant breakthroughs, which don’t affect the model of the
system at large. Deep but narrow, perhaps. A small enough subsystem
that I don’t consider it the systems model.

Chris: Or if you start with a bad enough model, getting to a mediocre

one is quite a breakthrough.

Eric: And I think I’ve experienced multiple breakthroughs in the same

project.

Russ: (Looking at a chapter head chart, re the breakthrough pattern)
I
don’t really get what this chart is trying to tell us. So this is time

marching along…

Eric: As you refactor again and again, and then you have little jumps

of value, and at some point, voom! You get a big jump in value.

Tracy: So maybe the vertical line should be a little diagonal?

Eric: It’s at the granulation of significant steps. Imagine if the
horizontal axis is a year. So how wide would a 3-week change-over be?

Russ: So this is potential value vs. value delivered?

Eric: You’re trying to read a bit too much into this picture. What I’m

trying to express is that progress in refactoring, in what you get out

of it, is like punctuated equilibrium. You have a steady practice
which takes you to a point at which things change suddenly. On really

successful products. If the refactoring is just keeping you out of
total chaos, you just keep going and going and don’t get big jumps.
But when you’re improving the system, you get little jumps, little
improvements, and then occasional big jumps. The axes are kind of
vague since it’s trying to express things you experience. Things that

may be difficult to measure.

Mark: So the length of the jump? The height is the amount of code you

change?

Eric: No, more the horizontal axis. The horizontal axis is either
time, or amount of refactoring. If you’re keeping up, they’re the same

thing.

Mark: I’ve often seen that in a breakthrough, you can throw away a lot

of classes and methods. The jump is in the amount of code that
changes, in my experience.

Eric: What I’m trying to express is the value of the code. The
flexibility, the ability to do more and better things.

(comment): You could express this as shortening the arcs, reducing the

cost, the distance to some new things you could get to. New features.

John: If you take the derivative of Eric’s graph, you can tell what the

expression on the manager’s face is.

Russ: Let me talk out of both sides of my mouth now. I think I
disagree with the notion that all programming days are the same.
Productivity-wise. When you’re really where you want to be with the
model, you can accelerate in how much code you can write. Whereas when

you are trying to figure things out, you’re a lot slower. When this
doesn’t come early in working with the code, I feel you’re more in the

realm of re-engineering then re-factoring. There are no small steps
that get you out of the hole. Now we’re in the area where hopefully
there’s some piece on the outside that you don’t have to change, but
the stuff on the inside has to be radically changed around.

Eric: I think all these things can happen. I don’t like to get too
hung up on the details. I call it refactoring because it has the same

definition — changing the design without changing the behavior of the

system. It doesn’t say how big that change is. It’s good practice to
make these steps small and continuous. But sometimes you have to take

a leap across a big chasm. In a story I have later, fixing the core
stuff was quick, but fixing the stuff that depended on it took quite a

bit longer. Nowadays I might be able to figure out how to break that
design shift into smaller pieces. But three weeks was small in terms
of the total project.

Russ: For other people who have had the breakthrough experience?

Chris: For us, I’ve seen it where “everyone gets Friday off except
you,
you, and me.” Then the change happens over the weekend, and everyone

picks up the new architecture on Monday.

Eric: There was a point at which a team I was working on got rid of the

EJBs in their system. They’d been whittling them down over time, and
at the last point, they took their last few EJBs and ripped them out
over a weekend. Sometimes you have to say hands off the code.

Chris: I find that that tends to be a property of the “aha”
story.

John B: Or if we just move one thing, suddenly everything else becomes

much easier.

Chris: I tend to think of those as “d’oh”s rather than ahas.

Tim: Sometimes you get in a stuck position where you end up getting
told, “Okay, you’re not making progress, just stop and think.”
Then
sometimes when you get an insight, you don’t have time to work out all

the advantages by the time you have to ship.

(Chris, Eric: discussion about software architects resisting a change

that simplified the model and made the architects’ job “too small”)

John B: When you ask the question, “Why is this code that way”,
and the
answer is someone’s name. That seems to be a recurring pattern of
dysfunction.

John B: Ward Cunningham’s talk, his metaphor about waiting for insight.

You don’t have to wait, but if you don’t it won’t come. And when you
get an insight, it can be like climbing a mountain. Going down the
other side is working out the implications of your advance in
understanding on the rest of the system. You can abort a climb, you
can climb to the top and plant a flag, or you can carry out the whole

thing, climbing up and carrying it down.

Eric: Businesses keep an eye to new opportunities constantly. They
don’t expect that they can predict things, that the environment will
remain stable. They look for new places where they can gain advantage,

new markets, new ways of simplifying things. You don’t see this search

for opportunities in software projects, and it’s rare you get the
serendipity you can get from just keeping your eyes open.

Eric: One of the things I worry about, on the highly iterative methods

of software development, especially frequent releases. It’s hard to
stay agile if you have a large installed base.

Tracy: The Poppendiecks’ book — Lean Software Development. They talk

a lot about experimentation. The right amount of experimentation is
when you succeed half the time. You learn something from your
successes, but you learn a lot more from your failures.

Carol: Detail-oriented people, are they different from ambitious,
entrepreneurial types?

Eric: The people who do manage to set up their organizations in the
right balance, who allow upside potential, they will leave the others

behind.

Robert: OK, you talk about sort of a portfolio approach in business,

trying out a lot of business opportunities. But there’s a difference
between software development and business opportunities.

John B: 3M does this with atoms, even. They’ve institutionalized a
version of what’s called “playtime” in Tom DeMarco’s work. When
one
company DeMarco described looked at their successes, all their
best-selling projects all came out of playtime.

Eric: And software development would be more fun AND more productive.

In squeezing out the fun, they’ve squeezed out their unexpected
opportunities. There are only unexpected bad things.

Robert: Evolution from a “big up-front specification and design

culture”.

Russ: The large corporate culture of software really followed a
grass-roots, individual level orientation at first.

John B: Everybody knew this who was any good. That you couldn’t
anticipate everything up front. That you should go through the whole
cycle of the project in miniature, early on. That you should deliver
something part-way through as a sanity check.

(comment): do people just have the wrong impression about software?
That it’s like architecture or manufacturing, large fixed costs with a

heavy process?

John B: Software is nothing but metaphor. What do we have here
(indicates Apple iBook), a chunk of LCDs and a backlight?

Russ: Is software like a magazine?

Mark: Like publishing? You can cut a few things out, the quality will

suffer, but you can still read the article.

Russ: Agile software methodologies beg to differ.

Eric: A literary journal?

John B: Or a math journal? Where everything is a proof?

…

John B: And the bad metaphors for software are based on
misunderstandings of the other fields. Even manufacturing isn’t like
manufacturing, as we learned from reading Lean Software Development.

Eric: Let’s take a break from the metaphors for a while. Just do
software development for a while, without saying it’s like anything,
and see where it takes us.

Carol: Why do people keep picking terms from other fields?
Programmers, analysts, engineers came in at some point.

Eric: For me, writing this book was like programming.

Jeff M: Did you have a breakthrough?

Eric: Yes, I did. Multiple breakthroughs. There was a point where I
realized I had to reverse the order of all the pages.

(wide ranging discussion of metaphors)

Chris: Shouldn’t you write down the list of the top 10 things you hate

about software development? These things need breakthroughs.

Eric: Companies want to produce software with unskilled labor.

Russ: I was wondering, for people who have had these breakthroughs.
Can you remember anything beforehand that led to the breakthrough? I
can remember sitting and thinking, “It just can’t be this hard.”
So
there was one time I recall looking at two sets of client
specifications for two different projects, thinking “these are too

similar to be different.”

Bob: I had a time when I was working on a project and that everything

seemed much too hard. So what I did was to step away from the
framework I was using and started by just sketching out classes. It
was a case of constantly running into something, stepping back, and
then bringing back my insight back into the system.

Chris: I’ve seen that “share pie” example from the other side.
(“share
pie”: referring to dividing up the moneys from a syndicated loan
as a
somewhat complex domain issue) The domain experts think of everything

as special cases, and when you put them together, you find out that
they are just slight variations of a strong central theme, and the
domain experts are startled.

John B: Duplication in the code that you can’t quite get at, the way

it’s organized. You can tell they are doing the same thing, but
there’s no way to put them together.

Eric: You think there’s a deeper model in there?

John B: Usually I think that it’s very annoying. And when I do little

refactorings, reducing duplication, bit by bit, finally I often realize

that there’s a way to fix the problem by introducing a new object,
perhaps.

Chris: It’s turned out in my experience that sometimes the domain
experts don’t themselves have the best understanding of the model.
Sometimes there are simplifications and unifications that can be made.

Eric: I’d draw a distinction between an expert who knows his field but

does not have an abstract thinking talent, versus someone who is only

borderline competent in the domain… I would work with someone who
knows things in detail but doesn’t have a clear abstract view, but I
would try to avoid working with someone who doesn’t have a firm grasp

on the field. You lose a lot by not having good give-and-take with
someone. Sometimes I turn to books about the field.

Russ: Has anyone (p.206-7) seen a better explanation than the brief
discussion here, of the nouns-as-objects vs. not discussion?

(“hmmms” from around the table)

Eric: Chapter 9 has something of a discussion for dealing with the case
where the local domain expert is not so available, or not so useful to
you. Sometimes you have to become a middling expert yourself. But it’s
a lot harder.

Tao: We’re about halfway through this book. From Chapter 1-9. It sort

of dawned on me. I used to be in manufacturing for a while. To be a
domain expert, you have to do it yourself. You have to go down to the

shop floor, to see the products, to find out for yourself how things
are made. Was it worth it, for the shipping example, say, for a
developer to try booking a cargo, or to sit beside the people who book

the cargo?

Eric: The people who book cargo don’t have a broad understanding. You

could learn what you needed from them in a few hours. I went to a port

and saw some port operations. It was valuable. I want to draw the
difference between a domain expert and a user. The user’s point of
view is what you get from sitting and booking cargos.

Chris: You’ll learn how it has been done, which is not necessarily how

it should be done.

Eric: I most like to work with a domain expert who has some ideas for
new ways to do things.

Chris: These seem to be on the endangered species list.

Darlene: How do you deal with a domain expert who is making mistakes
in
what he tells you?

Eric: Most of the things in this book assume that what the domain
expert says is basically true. That he’s not making mistakes.

John B: Although you would catch inconsistencies pretty quickly.

Eric: Or you would look at your model, your design, and ask about where

there are seeming contradictions or difficult points in the design. So

you might go read a book to see if you could get another opinion,
another angle on things. You might hear contradictory things from two

domain experts that you could resolve in this way. Or you might have
to go back and ask for clarification in the light of each others’
assertions. So you’d hear, “Oh yeah, I made a little mistake there,

it’s supposed to be like that.” Or you’d hear that you were missing

some context. Or occasionally you would get a sense that one is more
reliable thn the other.

John B: It’s like a Columbo episode. Eventually he’d tap his forehead

and say, “There’s just one thing bothering me…”

Eric: Software development is like a Columbo episode?

Chris: Refactoring is like a Columbo episode?

Tim: How often do people end up having to deal with “users”
rather than
“experts”? So sometimes we have to reverse-engineer the domain
out of
a usage pattern from a previous generation of application.

Russ: We’ve more often had the experience of building the first one of

a thing, so we as developers are considered as expert as anyone else on

the team. It’s a pleasant way to work.

Tim: So sometimes we’ve had to lead with a user interface. We walk
through them with the UI, and find out what we got wrong in our
understanding of what they wanted.

Eric: So, to do this, to do domain-driven design, you really need a
domain expert. I don’t say who it is. But not all domains are so
approachable that a software developer can be their own domain expert.

(reference to a glossary entry on “domain expert”)

Eric: The printed-circuit board design case, the example in the
beginning of the book. The domain experts were users. But many of the

users were narrower in their understanding of the domain. The people I

was working with had a somewhat larger vision, that the right tool
could help guide other users toward good practices in how they do their

work in PCB design. It reminds me a little of our earlier discussion,

a previous session, about writing OO code in a non-OO language.

Jeff M: What would you want first? Maybe long identifiers?

(laughter)

Jeff M: Then polymorphic dispatch?

Russ: Encapsulation first.

…

Tracy: You can go through 100 ideas in an hour and a half at the
whiteboard, at the level of concepts. If you tried to write up 100
ideas, how long would that take to run through the trial-and-errorl

Eric: Not only would I be at the whiteboard, but I would be speaking

out loud, that I would get the immediate feedback to move quickly.

Tracy: And the idea that it’s OK to float 100 ideas, that that’s a good

thing, that you can go through a lot of ideas to converge on a good one.

comment: One of the things that takes a lot of the fun out of
programming is that if the iterations are too slow, you don’t get the

reward of the feedback, the sense of progress.

Eric: You can end up in a local minimum through iterative development.

Then you might deliberately destabilize the situation, do a few things

to see if there’s a better place around.

(Russ describes annealing in metallurgy for strengthening metal, and

simulated annealing in numerical optimization)

…

Russ: (smile) Now we know that we aren’t getting enough reuse in
software because this bucket doesn’t show up later when we’re mixing
paint.

Eric: Did anyone get into the Specification pattern?

Russ: We’re supposed to read into Chapter 10.

Tracy: We’re ambitious.

Eric: Specification is supposed to serve as a case study…

Russ: Do you think you might run into a case where the situation would

be too complicated to be satisfied by the simple Specification you
describe?

Russ: Next week’s homework: Come in with an inappropriate metaphor for

software development.

(some discussion of the Wiki on domaindrivendesign.org and SVP’s wiki).

Russ: Who’s used this? John, raise your hand. (“Constraint”)

(looking at the Warehouse Packer prototype)

Eric: Sometimes you get into a design logjam, where everyone is waiting

for everyone. Just any implementation of one of the subsystems allows

everyone to move forward. Even a dumb implementation of the piece that

fulfilled the contract gets things going.

comment: We had a teaching software implementation where the
“intelligent” part of the interface started out as a random
number
generator. And it was surprising how long people thought there was
something more intelligent and complex was behind it.

Russ: We’ve found out for things like the prototype that it can be hard

to move from the simple prototype, beyond to the more complete system.

You need more global organization and structures to support where you

need to end up.

Eric: Obviously a lot of optimization problems require global
reasoning. That just makes sense. Still, the analysis that goes into
doing a thing like having

Chris: (to Russ) When you needed to back out the constraint code to
optimize the packing, did you lose the ability to use the constraints

as pure validation? “Does this solution satisfy…?”

Eric: I think he means, how do you know you’re answer is right?

Chris: Yes, the basis for your tests.

Tim: Some problems are so hard that the ability to prove it optimal is

the same level of difficulty as being able to create the optimal
solution.

John: What you’d do is set some sort of floor.

Eric: Would you have been able to go directly to the final, optimized

solution? Or would the prototype be useful for clarifying the
structure of the system?

…

Russ: We had a prototype Builder, a complex but low-risk piece of work

in full, where the prototype handed back one of three representative
structures of the types of things we wanted to work on. Having the
prototype helped the rest of the system take shape.

Tim: It helps for more than just the first pass to break the logjam.

Russ: The prototype builder actually lasted much longer than we
expected.

Tim: We had a brute-force temporary optimization module that was just

supposed to keep us developing until we signed the contract with the
optimization engine company. Which never actually happened.

Yahoo! Groups Links

To visit your group on the web, go to:
http://groups.yahoo.com/group/siliconvalleypatterns/

To unsubscribe from this group, send an email to:
[email protected]

Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/