mca blog

my post is careless in referencing "DDD." i link to "design-driven...", tagged it w/ "domain-driven.." and thereby lumped design issues w/ development. thanks to @BradleyHolt for helping me sort out my mistake.

fwiw, there are more than enough contenders for the first "D" in "DDD" : Data, Domain, Design, etc. i am sure there are more.

i think my primary point remains: the increased focus on development practices based on changing human behavior may be missing the mark. more attention should be given to creating programming environments that accept and take advantage of current distributed network realities.

but i'll let the reader decide.

lately, i've been thinking about the spate of "[insert-letter-here]-driven development" methodologies|approaches that have appeared in the last several years: TDD, BDD, DDD, etc. and, as i thought about them, it seemed to me that not only do they each attempt to solve the same general problem (dealing with the vagaries of a fast-paced, heterogenous, computing environment), but they also share another basic similarity: they focus primarily on managing human behavior and communication.

and that's where [T|B|D]DD is (IMO) making a mistake.

see, i think it's not the communication between people that is the problem, it's the communication between components on the network. IOW, it's the architectural model that needs attention right now, not developers.

Design-By-Contract

i think Meyer had it pretty close with his DbC pattern. in fact, i appreciate Meyer's willingness to build an entire software system (Eiffel) designed to lead programmers along the DbC path. however, i think today's programming environment has morphed to the point where the details of Meyer's contract model result in implementations that are too brittle and static to successfully support the long-lived, quickly-evolving applications most developers encounter today.

don't change the developers, change the environment

instead of following along the path taken by the [T|B|D]DD crowd, i think it's important to consider, like Meyer almost 20 years ago, the idea of changing the programming paradigm in ways that encourage developers to "do the right thing" as often as possible. since so much of what we deal with today involves the Internet|Web, and all that goes along with it, i think it's important to look at models that assume the same characteristics as the Internet and to provide developers with tools and implementation patterns that work with that environment. one that assumes: 1) a widely-distributed network, 2) heterogenous components, 3) high latency, 3) unreliable connections, and 4) unstable content.

too often, i see programming tools, frameworks, and paradigms that try to shield developers from these realities in an attempt to continue to support the same programming patterns that worked two decades ago - before the predominance of the Internet. on the contrary, we need a model that accepts these attributes as "normal" and identifies general system properties that show developers the path to building reliable, responsive, and robust applications.

REST: a great architectural model, a lousy software framework

Fielding's REST model is one example of an approach to architectural analysis that accepts|embraces the natural properties of the Internet and works to identify desired system properties and ways to induce target outcomes. although often mis-understood, Fielding's model (along with some related ones) goes a long way toward providing developers a well-defined path toward building stable implementations that live on unstable networks.

unfortunately, too many developers and even software architects mistake Fielding's work as a prescription for software design instead of seeing REST as just one example of architectural style. this has lead many well-meaning coders to attempt to build "RESTful" frameworks and libraries that try to "freeze-dry" this single architectural style in the form of a collection of software patterns and coding restrictions. the result rarely does justice to Fielding's work and usually falls short of the intended goal.

however, that does not mean i think it is not possible to devise a programming model that encourages developers to align their work with Fielding's observations. in fact, i think the most likely vector for inducing this particular desired behavior in programmers can be found in a seemingly unlikely source: media types.

updating Meyer's approach

while i think Meyer's DbC is not well suited for today's Internet, i still think his general approach is sound: recognize the importance of shared understanding and outcomes (Meyer calls them obligations and benefits) and use programming patterns that lead developers to think and act in ways that acknowledge the constraints and encourage the outcomes.

in the "age of the Internet" the closest thing i think we have to Meyer's "contract" is the MIME Media Types. media type definitions encapsulate the same basic elements identified by Meyer (what is expected, guaranteed, & maintained). they describe the elements passed between parties, the read/write semantics that can be applied to those elements, and how the underlying protocol can be used to ensure a full understanding of what is maintained by both client and server.

by focusing on media type design itself, rather than on the components and connectors that use the media type, developers have at their disposal a detailed and reliable description of the "shared understanding" (i.e. "contract") between parties that can result in system designs and implementions that follow the guidelines laid out in the documentation of the relevant media types. in addition, there is more than enough history and guidance on ways to maintain and evolve that shared understanding over time in order to create a stable and flexible environment that can meet both current and future needs without requiring major re-investment of time and energy when new requirements arise.

so there you have it

it's true that we need to teach developers to build applications that have fewer initial errors, break less often at runtime, and are easier to maintain over time. we don't, however, need to rely soley on training developers in detailed human interaction patterns in order to achieve that goal. we should also provide developers with a programming environment that makes it easier for them to design and implement robust, reliable components for the Internet "as is" with all it's quirks and faults. and to do that we need to leverage the most dependable "contract" we have. the one that has proven over the last decade to work well when defining interations between heterogenous parties on an unstable, unreliable, high-latency distributed network.

we need Media-Type-Driven Development (MTDD)

or maybe it should be called

Design-by-Media-Type (DbMT)

or then again...

Media-Type First Programming (MTFP)

well, you get the idea. for now, just use media types to establish clear understanding between parties, ok?

i'll work on the marketing stuff later.