Virtual Genius

September DDD Immersion Class Sold Out!

Tue, 09 Aug 2011 16:25:47 +0100

The September DDD Immersion class in Denver is now full. I'm really looking forward to teaching this one, as there is a certain energy and level of fun that comes from having a full complement of people, particularly for the group domain modeling exercises.

Earlybird seats are still available for the classes running in NYC in November and in Denver in January 2012. Don't leave it too late though, as they are tending to go fast.

Upcoming Domain-Driven Design (DDD) Immersion classes

Fri, 22 Jul 2011 19:37:08 +0100

I wanted to let everyone know I will be teaching two of the public DDD Immersion classes for Domain Language between now and the end of this year, one in Denver and one in New York. Seats are still available for these classes, but likely to go fast. The early bird discount for the September class in Denver is still available at this time.

Go to http://www.domainlanguage.com/training to register.

Here is the schedule:

Sept 20, Denver, CO

DDD Immersion
Instructor Paul Rayner
$2790 $2090 if booked by 8/12

Nov 29, New York, NY
DDD Immersion
Instructor Paul Rayner
$2790 $2490 if booked by 10/21

For those of you who are perhaps not familiar with the DDD Immersion, it is a 4 day deep-dive into creative domain modeling, combining hands-on coding with group modeling exercises for a truly immersive learning experience. I attended the class in February in NYC in Feb of last year, and wrote in detail about my experience. Since then I have become a certified DDD Immersion instructor.

Here is what a typical class looks like:

Day 1: Model Exploration and Ubiquitous Language

Domain-driven design overview
Making implicit concepts explicit
Ubiquitous Language

Afternoon: Jumping in with code

Brainstorming models
Expressing a model in software
Building-block patterns (entities, value objects, repositories, etc.)
Test-first development as a modeling process

Day 2 Morning: Modeling with Domain Experts

Techniques and pitfalls of bringing about a creative collaboration.
Modeling out loud

Day 2 Afternoon: Supple Design

Patterns and techniques to tighten models and their connection to code.
Making code obvious, easier to use and change
Modeling for transactional integrity and distributed systems

Day 3: Strategic Design

Morning: Context Mapping

Pragmatic approach to dealing with diverse models and designs on real projects
Relationships between subsystems/ relationships between teams

Afternoon: Distilling the Core Domain

Distinguishing the core from the mass
Ways of focusing effort
Clarifying a shared vision
Setting up a project for success

Day 4: Bringing it Together

Design/code challenge - model supple design with context map
Round-table discussion of SOA and enterprise frameworks with DDD
In-depth discussion and Q&A, relating all topics to each other and to your own work

Your class was a great experience on many levels…of course what I learned about DDD - fabulous - but also how you taught the class and the interactive nature of it is just wonderful.

Julie Lerman, Author of Programming Entity Framework.

Unlike some trainings and courses I’ve experienced, I don’t think anyone left this course without a very solid understanding of how they can better pursue DDD in their own environments.

Brian Donahue, May 2010

There is also another Denver public class scheduled for January - for those who like sunshine with their Winter snow!

Jan 17, Denver, CO
DDD Immersion
Instructor Paul Rayner
$2790 $2090 if booked by 12/2

I should also mention that Domain Language can also provide DDD Immersion classes and DDD consulting onsite for your team.

Don’t give your customers what they ask for

Thu, 21 Jul 2011 19:24:26 +0100

Give them what they need

There is a pairing exercise participants experience in my BDD with Cucumber workshop where one person describes a commonplace activity to the other. The challenge is describing it without being able to use certain common words. You need to attend the workshop to see what this looks like, and how much fun it is (I'll post a short video of participants soon).

One thing I have noticed, no matter where I have run this exercise, is that very few people actually explain why this activity should even be done. They typically spend all the time describing the mechanics of how to do it, but don't explain why, and the listener usually doesn't think to ask. I contend that as technologists we do the same thing to our customers all the time.

The critical piece here is asking "why?"

Ask your customers, "why do you need this?" "How will it help you?" "What problem does having this feature solve?"

And then ask "why?" a few more times. Failure to do this will lead to a mechanical understanding of the need rather than the type of creative collaboration that might lead to deep insights about the true problem being addressed. I think it is this lack of deeper questioning that explains how many user stories lack a clear statement of the benefit returned by implementing the feature described by the story.

I really enjoyed reading Tom Preston-Werner's post Ten Lessons from GitHub’s First Year. Tom says it better than I ever could:

Adapt to Your Customers

Here’s a seemingly paradoxical piece of advice for you: Listen to your customers, but don’t let them tell you what to do. Let me explain. Consider a feature request such as “GitHub should let me FTP up a documentation site for my project.” What this customer is really trying to say is “I want a simple way to publish content related to my project,” but they’re used to what’s already out there, and so they pose the request in terms that are familiar to them. We could have implemented some horrible FTP based solution as requested, but we looked deeper into the underlying question and now we allow you to publish content by simply pushing a Git repository to your account. This meets requirements of both functionality and elegance.

In another post Tom points out how "building the right system" always trumps "building the system right":

I hear a lot of talk these days about TDD and BDD and Extreme Programming and SCRUM and stand up meetings and all kinds of methodologies and techniques for developing better software, but it's all irrelevant unless the software we're building meets the needs of those that are using it. Let me put that another way. A perfect implementation of the wrong specification is worthless.

Producing working software frequently is necessary but insufficient. Producing valuable working software frequently is what matters.

Some Reflections on Uberconf

Fri, 15 Jul 2011 19:35:00 +0100

If you do development on the JVM and you did not attend Uberconf this week then you really missed out. This is the second year of Uberconf in Denver, and it just keeps getting better and better.

Even though I was not able to attend the entire conference, I feel like I come away from my time there with new friends, new knowledge and some great memories.

Some takeaways

Thanks to all those that attended my sessions. I was also very impressed by the level of questions and attendee participation. In particular, my BDD with Cucumber was packed, and most attendees hung around for the second half. One person told me she attended the conference mainly because of this workshop, so that was a nice thing to hear. As a side note, it doesn't matter how much you check your class materials, it only takes one faulty USB key to throw a wrench in the works. Presenters beware!

The group exercises I use in my BDD with Cucumber workshop (thanks to Richard Lawrence for letting me use them!) have been great ways to clarify the material for attendees and get everyone interacting with each other and having fun. I was aiming for it to be the funnest workshop at the conference - hopefully I came close!

I now know about some especially cool ways to improve my developer experience on OSX that I will be trying out in the weeks to come, such as Brew, MacVIM, Solarized and oh-my-zsh. Thanks especially to @arthurkalm for all the tool-foo sharing. Man, that guy knows his stuff.

Use ant -emacs to have Cuke4Duke output code snippets more cleanly. Thanks Howard Ship!

If you attended the workshop (or any of my sessions) then I would love to hear any feedback you might have, especially if you try implementing any of the things I talked about.

If you ever have the chance to attend a workshop by Venkat, don't miss it! He turns live coding into a performance art. Seriously.

Thanks to Jay Zimmerman, Ben, NFJS and staff of the Westin hotel for making Uberconf such a great event.

Learning About Lean and Agile Software Development

Fri, 13 May 2011 18:30:01 +0100

This year I have started giving a presentation for No Fluff Just Stuff conferences that introduces many of the most critical ideas from lean software development, and provides some practical ways to start implementing them in whatever project context you find yourself: agile, traditional, or otherwise. Here is the presentation abstract:

Successful software development is about building the right product at the right time for your customers. This means focusing attention on the right places in the portfolio of projects and products that your company provides, and optimizing the entire value stream from "concept to cash" for your customers and the development teams.

Agility is more than just adopting Scrum or some other agile process framework; it involves adopting a new set of Lean-Agile values, principles and practices through the entire software development lifecycle and beyond in order to provide value to customers earlier and more often.

Lean-Agile software development consists of frequent feedback loops, intense team collaboration, continuous improvement, business and customer involvement, baking quality in and consistent delivery of valuable software. Learn how these Lean principles and practices transform software development and the radical difference it can make in your development work and wider organization.

Lean software development is a subset of Lean Product Development, not Lean Manufacturing. It is foolish to blindly apply Lean Manufacturing practices to software development. The underlying principles of value, flow, pull and waste remain the same, but the way these principles are applied to software development will look fundamentally different.

As Paul Hodgetts points out in his excellent Lean is More white paper:

Treating software development as Lean Manufacturing leads us down a path of optimizing the mechanics of developing software, which can yield limited benefits but fails to address the much larger software product development issues.

I would put it even more strongly than this. Most of what software developers do is invisible, particularly when it comes to the thinking involved with design.

It's just not about the mechanics of the process, any more than writing a song is about the mechanics of playing the instrument or enjoying a meal is about the nutritional content of the food. Such reductionism is a false hope for improvement. For example, seeking to create a more efficient process by reducing or eliminating design-related activities in software development as waste (such as design meetings, writing design documents, refactoring etc) will inevitably lead to a product with little conceptual integrity, and fast-track it towards becoming a Big Ball of Mud. Asking developers to track hours as a measure of productivity is the fast-track to disfunction and decreasing productivity. Let's not reintroduce Taylorism to software development through the back-door of Lean.

Agile methods were developed by assembling the best practices from successful projects. While the combinations of best practices found in agile methods exhibit the core values and principles of a lean approach, it can be difficult to understand the reasons why agile processes work just from examining their practices...Mapping agile practices to lean concepts such as value, flow, pull and waste can help explain why agile works, and offer new insights to guide process improvements. (Hodgetts, p. 3)

To see this more clearly we can look through at Kanban and Scrum the lens of lean and agile principles. Kniberg and Skarin, in Kanban and Scrum: Making the Most of Both, point out that Scrum and Kanban are both aligned with the values and principles of both Lean and agile. For example:

Scrum and Kanban are both pull scheduling systems, which corresponds to the JIT (Just in Time) inventory management principles of Lean. This means that the team chooses when and how much work to commit to, they "pull" work when they are ready, rather than having it "pushed" in from the outside. Just like a printer pulls in the next page only when it is ready to print on it (although there is a small and limited batch of paper that it can pull from).

Scrum and Kanban are based on continuous and empirical process optimization, which corresponds to the Kaizen principles of Lean.

Scrum and Kanban emphasize responding to change over following a plan (although Kanban allows faster response than Scrum), one of the four values of the agile manifesto.

While the batch sizes in Scrum are much larger (batching work into timeboxed iterations) and thus not as lean as Kanban, producing shippable code every 2 weeks is certainly much leaner than a more traditional process which might integrate and release something 2-4 times per year. The shorter you make the iteration, the more you are approaching Kanban.

As a DDD practitioner, one area where I think the careful application of Lean thinking holds a great deal of promise is in strategic design:

Agile and lean are not in conflict with each other as they may seem at first glance, nor are they incompatible approaches to process improvement... Lean Product Development offers several strategies and practices that can supplement agile methods, particularly in areas where agile methods have been criticized as lacking...the strategy of set-based design offers a balanced alternative to heavyweight up-front design approaches on one hand, and reactive, emergent approaches on the other." (Hodgetts, p. 3)

Instead of teams feeling that they constantly have to adopt expedient design approaches to meet Sprint deadlines, Lean thinking combined with strategic DDD frees them to focus their design work where it matters most for the competitive advantage of their business. It encourages them to reduce the amount of code they write themselves, cultivate domain knowledge, and explore models collaboratively with the business to maximize the potential to develop innovative custom software solutions that leap ahead of the competition in the marketplace.

To learn more about Lean Software Development, I highly recommend Implementing Software Development by Mary and Tom Poppendieck. This book is the definitive work on the subject at the moment.

How do we get our organization, especially our stakeholders, on board with strategic design?

Sat, 07 May 2011 16:31:37 +0100

Great question. Most stakeholders would be delighted that you are seeking to distill down your core domain. Not that they would express it in DDD terms, but rather that want to see that development effort is being apportioned appropriately according to the business strategy.

One approach would be to start by writing out the major business capabilities you are trying to achieve with each project. Put each one on a sticky note, and assign it to a quadrant in the Purpose Alignment Model.

Try to mark each capability according to the approach you are taking - are you currently treating each as core domain, supporting subdomain, or generic subdomain? Look for inconsistencies. For example, do you have business capabilities in the Maintenance quadrant? I would recommend killing all custom software development in this quadrant. Outsource those capabilities as soon as possible. Don't waste time on custom development. Don't waste time trying to support those capabilities at all.

Do you have parity capabilities that you are trying to implement using a core domain approach? Over-investment! Look for ways to use open source or 3rd party tools for generic subdomains. Hire contractors, and free up your in-house developers for supporting subdomains.

Do you have differentiating business capabilities that are not mission critical for your business that you are currently doing in-house? Find a business partner that excels at these. Ask for recommendations - who in the industry is best at this? Approach them about collaborating on a solution.

Like many development divisions/teams, you may be drowning in parity work. Trying to be too creative in your software development efforts for supporting subdomains and doing custom development for generic subdomains will leave little time for creativity in the core domain. Do everything you can to eliminate waste in your project portfolio by aligning effort and innovation to purpose. If you could reduce the amount of parity work on supporting and generic subdomains even a small amount, this would start to free up time, talent and energy to focus on your core domain.

Does the Core Domain Change Over Time?

Sat, 07 May 2011 16:20:41 +0100

Does the Core Domain change over time?

Yes, it does. As the marketplace changes and the business adapts to those changes, it must adopt new strategies to gain market share and enter new markets. Strategy changes will typically lead to Core Domain changes, as the areas of the software that support business activities that generate differentiation in the marketplace also change.

Strategic Design using DDD - Mile High Agile Conference 2011

Fri, 08 Apr 2011 19:06:37 +0100

I've uploaded the slides from yesterday's presentation at the Mile High Agile Conference here in Denver to SlideShare, and included them below.

I wanted to say how impressed I was with the conference. Around 500 attendees, 4 tracks and an open space! This was a lot for the organizing committee to bite off, but the conference exceeded everyone's expectations.

It was great to be a presenter, and also Sponsor the event through The Agile Cooperative and be able to give away a prize. I was proud to be part of the event, and thank those who attended my session at the end of the day and gave me such great feedback.

Strategic Design - Meh?

One interesting question I was asked is why isn't strategic design a more popular conference and agile community topic?

I don't know. In terms of the actual session itself, I felt that it was well-attended, and that everyone was very engaged through the presentation. In terms of the mechanics of the talk, next time I won't need to rely on my notes like I did yesterday. For the timeslot, I was also up against Bob Hartman and other popular presenters.

As to the broader question of lack of focus on strategic design in the agile community, I think that is a topic for another blog post. Stay tuned - there were a number of great questions during and after the session, and I will respond to them all via blog posts in the coming weeks.

Improving my Presentation Title - Free Prize!

Another reason - I think - is the pedestrian title for the presentation. Perhaps I need to spice it up a little.

Here are some tongue-in-check (or not) suggestions, feel free to propose others:

How agile development killed design
Scrum is the worst thing that every happened to strategic software design
Agile design - how did we get so far off track?
Why is agile design rarely strategic?
Strategy and Design - finding a line of sight
Aligning strategy and agile design
...?

What do YOU think I should call future iterations of the talk? I'll send a free copy of Eric's DDD book to the best suggestion.

Strategic design using ddd

View more presentations from Paul Rayner.

New Domain-Driven Design (DDD) Article in The Architecture Journal

Fri, 26 Mar 2010 15:12:00 +0100

The article that Brandon Satrom and I cowrote for The Architecture Journal, Issue 23 has finally been released to the wild. Our article is titled: “Keeping Architectures Relevant: Using Domain-Driven Design and Emergent Architecture to Manage Complexity and Enable Change.”

The overall issue is titled Architecture Modeling and Processes, and also includes articles on topics such as “Modeling in an Agile Context”, “Software Architecture in the Agile Life Cycle” and “UML or DSL: Which Bear is Best?"

One thing I should mention is that Figure 2 in our article is intended to be descriptive, rather than prescriptive. This is possibly not clear from the context in the article, and something we realized only after the article was well past the point of making changes in the editorial process. In some situations there may be several Bounded Contexts within a single Ubiquitous Language, and in others the Ubiquitous Language may be contained within the Bounded Context. This becomes more important as you consider Context Mapping, so I wanted to make sure this is clear.

Brandon and I are very interested in feedback on from our readers, so please post any comments about the article here or on Brandon’s blog. I want to thank Brandon for making writing the article such an enjoyable learning experience.

From the introduction to our article:

Keeping Architectures Relevant: Using Domain-Driven Design and Emergent Architecture to Manage Complexity and Enable Change

Brandon Satrom
Thought Ascent, Inc.

Paul Rayner
Virtual Genius, LLC.

March 2010

Summary: Sustainable and successful software development is all about managing complexity and enabling change. Successful software architects create designs that clearly address both concerns. For businesses that have complex domains, designing with evolution in mind and using techniques from Domain-Driven Design will result in systems whose architectures deliver a strong, sustainable competitive advantage.

Links:

The Architecture Journal, Issue 23.

PDF version of Issue 23.

Keeping Architectures Relevant: Using Domain-Driven Design and Emergent Architecture to Manage Complexity and Enable Change.

What is Acceptance Test-Driven Development?

Tue, 16 Mar 2010 09:44:00 +0100

Acceptance Test-Driven Development (ATDD) employs the approach of specification by example. ATDD is also known as Storytesting or Behavior-Driven Development (BDD).

Instead of talking in abstract terms about what the system will do, the team collaborates to create specific examples that specify what the system should do from the user's perspective. These executable specifications function as acceptance criteria for the user stories the team is developing. The team specifies as concretely as possible what the specification is, and then the developers code enough of the system to make the test pass to satisfy the acceptance criteria for that specification.

Frameworks such as Fit and Cucumber provide the means to embed this kind of collaboration into the development process. As Mugridge and Cunningham point out:

“[ATDD]…tests are a natural way to help develop this ubiquitous language. Such tests provide a comprehensive bridge between discussions of business need and software design. Writing concrete examples as tests explores ways in which to use and evolve the ubiquitous language for expressing business objects, constraints and rules.”

Fit for Developing Software: Framework for Integrated Tests, by Rick Mugridge and Ward Cunningham. (p. 336)

Cucumber, for example, is such an amazing ATDD tool because it’s so good at mapping stories and acceptance criteria to automated functional tests. Product Owners and BA's write acceptance criteria in natural language. Developers and testers unobtrusively automate tests for them. Anyone on the team can run the tests and see the current state of the system.

Those wanting to learn more about using Cucumber for ATDD can schedule a private training course, or attend our next public course in Denver.

Additional resources on ATDD: