The faller’s wedge & ubiquitous language

This post was imported from blogger, to see the original, likely better-formatted post see kalebpederson.blogspot.com.

>

I’ve recently been reading Domain-Driven Design, by Eric Evans. One of the foremost things Evans discusses is ubiquitous language, which he defines as:



A language structured around the domain model and used by all team members to connect all the activities of the team with the software.


Without that shared language, problems ensue. The following story, told by Samuel T. Whitman, illustrates well what may happen without a common shared language:



“The ice storm [that winter] wasn’t generally destructive. True, a few wires came down, and there was a sudden jump in accidents along the highway. … Normally, the big walnut tree could easily have borne the weight that formed on its spreading limbs. It was the iron wedge in its heart that caused the damage.

“The story of the iron wedge began years ago when the white-haired farmer [who now inhabited the property on which the tree stood] was a lad on his father’s homestead. The sawmill had then only recently been moved from the valley, and the settlers were still finding tools and odd pieces of equipment scattered about. …

“On this particular day, [the lad found] a faller’s wedge—wide, flat, and heavy, a foot or more long, and splayed from mighty poundings. [A faller’s wedge, used to help fell a tree, is inserted in a cut made by a saw and then struck with a sledgehammer to widen the cut.] … Because he was already late for dinner, the lad laid the wedge … between the limbs of the young walnut tree his father had planted near the front gate. He would take the wedge to the shed right after dinner, or sometime when he was going that way.

“He truly meant to, but he never did. [The wedge] was there between the limbs, a little tight, when he attained his manhood. It was there, now firmly gripped, when he married and took over his father’s farm. It was half grown over on the day the threshing crew ate dinner under the tree. … Grown in and healed over, the wedge was still in the tree the winter the ice storm came.

“In the chill silence of that wintry night, … one of the three major limbs split away from the trunk and crashed to the ground. This so unbalanced the remainder of the top that it, too, split apart and went down. When the storm was over, not a twig of the once-proud tree remained.

“Early the next morning, the farmer went out to mourn his loss. …

“Then, his eyes caught sight of something in the splintered ruin. ‘The wedge,’ he muttered reproachfully. ‘The wedge I found in the south pasture.’ A glance told him why the tree had fallen. Growing, edge-up in the trunk, the wedge had prevented the limb fibers from knitting together as they should.”



The Communication Schism

A chasm, or at minimum a schism, often exists between domain experts and developers. Domain experts often use terms that are inexact or ambiguous. Developers use terms specific to themselves and that describe implementation details. This leads to fracture in in both communication and the domain model. This fracture happens at all levels of communication. Without a ubiquitous language used by all team members and the domain experts who largely define the software, a gap between understanding and implementation grows.

Domain experts often use terms that are inexact or ambiguous. Developers use terms specific to programmers and describe implementation details. This leads to fracture in in both communication and the domain model. This fracture happens at all levels. Sometimes it may be a small schism and other times it grows into a chasm.

Without a solid base, a ubiquitous language to meld the domain expert’s knowledge with implementation, it is as if there’s a faller’s wedge stuck in our limbs. Our communication avoids certain aspects of the domain, circumvents necessary detail, and ignores relevant issues.

As this happens time and time again, both developers and domain experts become hardened, they don’t see the issues nor understand how to resolve the differences. Rather than build up knowledge, it is skirted and worked around.

In Domain-Driven Design, Eric teaches us how to overcome these problems. I highly recommend it.

No comments yet.

Leave a Reply