the 'bee log

Ubiquitous Language in Product Development

Dave Laribee — Wed, 24 Jun 2009 21:15:00 GMT

Hi there.

I got this question from a fellow named Martin today:

Real simple ... most of the discussion on DDD surrounds the design in terms of the ubiquitous language.

What if you are developing a product that is designed to be a tool for a certain industry, say marketing, but the processes and terminology all differ according to the marketing company that is in discussion.

To be specific, one company may use the term Client and the other Customer?

How do you accommodate the difference in terms? Do you code to a common denominator or do you just pick one and go?

Great question; in product development we're often trying to make a general solution that solves the common problems of customers that have different languages. There's no way around that.

First, find those elements that are universal. Question if there's really a need for all of this customization or if your clients are OK with calling a client a customer. Having a ubiquitous language that can be used end-to-end, from developer to end user, is extremely valuable and kind of the original point.

For variable terms you should, in my estimation and experience, form an internal ubiquitous language that's adhered to across product management and software development. In cases like this, you'll can potentially also apply DDD guidance to a generic subdomain that handles terminology. This domain usually goes by the name "localization," only slightly extended to allow clients to change terminology. This is exactly how we handle the differences in terminology (silly) between agile methods like Scrum and XP in our product at VersionOne. We simply have a set of components that handle the change between backlog item and story, iteration and sprint, etc.

Announcing the Lean Kanban Conference

Dave Laribee — Tue, 06 Jan 2009 14:44:00 GMT

I've been working with David Anderson and crew to produce the Lean Kanban Conference in Miami, February 18th-20th.

There are a number of great speakers and some folks that have been practicing Kanban and flexing Agile methodologies with Lean thinking for some time. For my part, I'm going to do a talk about introducing pull systems at the edges of an Agile team (based on experiences at VersionOne), JIT'ing retrospectives, and rethinking software development activities and practices -- architectures, continuous integration, source control -- through the Lean lens, which would have us release regularly (on a feature basis, in fact).

If you're interested in Lean Software Development and Kanban, this is the place to be. Register now!

Spicing Up Your Standup

Dave Laribee — Mon, 17 Nov 2008 01:58:00 GMT

Tags: luke-melia -is-awesome, funny

Ayende on Advanced NHibernate

Dave Laribee — Thu, 13 Nov 2008 14:02:00 GMT

There's this cat called Ayende that's been around the NHibernate block (20 or 30 times). In Austin, he did a 3-hour workshop detailing the advanced features of the tool. If you weren't there, sorry you missed it.

Oh wait! You're in luck; someone recorded it! The audio is a little quiet so be sure to, as the kids say, "pump up the volume."

Enjoy...

Designing the Team Room, Take 2

Dave Laribee — Thu, 06 Nov 2008 15:19:00 GMT

Based on the comments, a couple of clarifications on my "Designing the Team Room" post from yesterday.

The text at the bottom certainly does have contradictions and conflicts. That's by design. We wanted to see what people came up with, what ideas latched on to "productivity" versus "collaboration." The opening is simply for context. People that are up on Theory of Constraints will realize that defining conflicts and finding solutions based on root cause is, well, kind of the whole point.

I also neglected to detail the mechanics used for the design storm.

1. Each person tore of a sheet from a 3M sticky easel pad, grabbed a marker, and found a spot on the wall.
2. We had twelve (12) people stand in the circle.
3. I read the context statement I posted yesterday.
4. For 5 minutes, each person made a "design." Some of these were visual, some textual, some floor plans, etc.
5. We then counted off by threes to form a total of four groups (ones in one group, twos in another).
6. Each group member (within their group) had 1 minute to pitch their ideas.
7. After the individual pitches, we took another 5 minutes to synthesis a cohesive design.
8. The cohesive designs were presented to the entire group.

What was interesting is that this process took under 30 minutes and we got a little closer to consensus and got some really good ideas. And that was the point...

Designing the Team Room

Dave Laribee — Wed, 05 Nov 2008 18:53:00 GMT

At VersionOne, we just got the opportunity to move to a new team room. It's far superior in terms of size, noise level, and natural light. It's a very cool, very lofty kind of space. To get things started, we applied the "design storm" exercise which is a form of concurrent set-based design, an evolution of the old school architectural charette. Special thanks to @uxdesignermike who turned us on to this tool at KaizenConf. Mike, for the unaware, is awesome.

You'll find the opening I used to kick the session off below. I'll be sure to post a few follow up shots as we get our space together in the coming days.

In moving to a new, more-ideal space we have an unusual opportunity to optimize for collaboration, productivity, and fun. To get this process and involve the numerous smart and opinionated members of the V1 development team, we’d like to engage in a process called “the design storm.”

We have a few goals and constraints going into this:

We want to keep noise at an acceptable level.
We want an intensely collaborative environment.
We want the space to be flexible and permit promiscuous pairing.
We need spaces for breakouts and loud meetings.
We want stand-ups to remain unbroken (no walkthroughs).
We want to pay attention to traffic patterns.
We want to change it up every so often. Take that how you will.
We want our continuous improvement efforts to be highly visible and easily accessible.
We want the team to sit in the same area together (i.e. no cave dwellers).
We want to leverage natural light the best we can.

I’ve hinted at this, but our main motivations are:

Collaboration – proximity promotes knowledge sharing.
Creativity – ours is a creative job. it should be easy to start designing stuff.
Productivity – it’s easy to focus and get stuff done.
Awareness – looking at the walls yields information.
A pleasant working space is, well, pleasant.

Now, without pre-designing the space, does anyone have anything else?

KaizenConf Workshops Schedule

Dave Laribee — Mon, 27 Oct 2008 04:32:00 GMT

UPDATE: We will try to record the full sessions. I'm hoping some participants will bring video cameras and have at it. I'm bringing mine.

First of all the temporal situation:

Morning Sessions - 9a-Noon
Afternoon Sessions - 1:30p-4:30p

Then, we have to talk about the nomenclature around and sizing of rooms:

Huge - 50-60 people
Large - 40-50 people
Wimpy - 15-25 people

Thursday Morning

Huge - Advanced NHibernate
Large - Introduction to Lua
Wimpy - Pull, Don’t Push: Lean Systems and Kanban

Thursday Afternoon

Huge - Functional Programming - Is it a game changer?
Large - DSLs in BOO
Wimpy - Driving Toward the Goal

Friday Morning

Huge - Using and Abusing ASP.NET MVC for Fun and Profit
Large - All About MEF (the Managed Extensibility Framework)
Wimpy - Mystery Session with Scott Bellware

Friday Afternoon

Huge - Presentation Patterns: Going beyond MVP and Presentation Model
Large - Fluent APIs with C# 3
Wimpy - DDD Chalk Talk

The Value of Lean and Kanban

Dave Laribee — Thu, 23 Oct 2008 21:42:00 GMT

Mark Levison wrote up and introductory article on Kanban for InfoQ. It's from a people perspective and worth a read if your new to this scene or interested. I'm especially happy he conveyed the "work to done" concept.

For me that's the biggest thing. Done has a pretty simple definition: "it's in production." I think this is a message that should be in the forefront. As with any message, repetition is key.

Throughput accounting (David Anderson's book on Agile Management, great intro) is a big, big, big deal. This is the theory/justification/whatever of the done definition.

The other thing that's really important to me is the visual management stuff. You can see where things are getting bogged down. Corey Ladas pegged this best in his leading indicators post. Queue utilization trumps velocity/cycle time in having an effect on throughput.

Standard work and thinking about your pipeline is rather critical. Continuous improvement happens much more regularly when we say "hey, here's how we're gonna work" and make that explicit with a whiteboard, cards, and a marker, and tweak over time. There's gotta be a baseline.

Other things, like cycle time, seem less important (but still matter) as, in the case of cycle time, it's just a re-imagining/slight reconfiguration of an agile concept (velocity). Of course it's important to establish it and improve upon it, but I don't necessarily see it as new ground.

Presenting the KaizenConf Workshops

Dave Laribee — Wed, 22 Oct 2008 05:35:00 GMT

UPDATE 1: Schedule is coming tonight. Each workshop is approximately three hours long. We're going with a longer form to get more knowledge transfer, interactivity, etc.

UPDATE 2: Based on space and time constraints, there will be two sessions going on at once. No tracks (we don't do tracks), but I will make an attempt to provide some variety.

Here's the final lineup for the workshops immediately preceding the KaizenConf Open Spaces event. I'm pretty psyched about the line-up. There's some very relevant/edge topics covered by seasoned people chock full of juicy content.

ALT.NET assemble!

Advanced NHibernate

Ayende Rahien

Object relational mapping are becoming only more popular, as people developing complex systems find that they need more than the tabular model to work with in their applications. A sophisticated ORM can do a lot more than merely get the data out of the database in object form, it can be a valuable asset in simplifying development and making things possible. In this session, you will see how you can utilize an ORM in nontraditional ways to get an additional, better, approach to solving complex issues.

Some of those ways include business rules, localization, state transitions, inversion of control, etc. All done via the ORM layer, and all can be used to drasticly simplify the complexity of the given scenarios.

Presentation Patterns: Going beyond MVP and Presentation Model

Jeremy D. Miller and Glenn Block

Our desktop applications are becoming more complicated every year, and just slamming all the behavior into the code behind isn't cutting it any more. You know about Model View Presenter and Presentation Model for individual screens, but what about the application as a whole? How do you govern screen activation? What about communicating across screens? Extensibility? In this session I'll present some patterns and strategies for handling complex behavior in stateful clients. We'll examine some possible approaches for using IoC tools to wire together a composite application. I'll also present on the screen activation lifecycle, state management throughout the application, and coordinating events over an application. Taking another tact, I'd like to examine the MicroController pattern combined with language oriented programming as a way to wring out more productivity in our development efforts.

Time permitting, I'll also share some lessons learned for automated testing of desktop applications.

Fluent APIs with C# 3

Chad Myers

You may not know it, but you're likely already using internal DSLs in C#: The Linq IEnumerable extension methods (Select(), Where(), ToArray(), etc), the NHibernate ICriteria API, Rhino Mocks, StructureMap, Windsor, Moq, Ninject, and many others all have internal DSL syntaxes. Whether it be for configuration, programmatic assembly of an object graph, or a myriad of other purposes, an internal DSL can usually make the process go faster, easier to test, and easier to consume by the API consumer.

In this workshop, we'll go through the process of creating a basic internal DSL. We'll then go deeper into more advanced variations and themes of internal DSLs, learn about tricks and pitfalls, and end up with an advanced internal DSL. We'll learn about method chaining, the builder pattern, function sequences, and many other internal DSL patterns and related concepts.

Using and Abusing ASP.NET MVC for Fun and Profit

Jeremy D. Miller & Chad Myers

After deciding to go with ASP.NET MVC Preview 2, we quickly ran into a few design/testability problems and some missing functionality we needed (it's a preview, after all). Still agreeing that ASP.NET MVC was good and still worth pursuing, we decided to begin filling in some of the gaps and trying to avoid some of the testability problems by creating our own extensions and overriding certain behavior. Jeremy has come up with some great concepts during this process that we'd like to share with the community.

During this workshop, we'll go through the various additions and derivations we've made in our ASP.NET MVC-based application and how they've helped us create a very adaptable, reusable, and testable web application infrastructure. The goal is to discuss and contribute ideas to the community, suffer critical feedback, and hopefully increase interest in MVC-based design and testability in a web environment.

Introduction to Lua

Marcus Irven

Lua is a powerful, fast, light-weight, open source, scripting language. Though Lua can be used for standalone applications a lot of its power lies in how can easily it can be used to extend programs written in other languages.

In this workshop you will get a thorough introduction into the Lua language. After covering the basics we will dive into code and explore the interesting and unique features of Lua. You will also get an introduction on how Lua can be used to extend your applications.

Functional Programming – Is it a game changer?

Matt Podwysocki

We hear a lot about functional programming lately, and many wonder the reasons. We’ll dig into the philosophy of functional programming, how you can apply it, and what uses it has. Immutable by default, recursion over mutation and functional composition over inheritance are some of the mind shifts required for this technique. As we run into Moore’s law changing, we need to be aware of how to realize the full potential of our applications when it comes to asynchronous and concurrent behavior.

Learn how functional programming can help solve some of these problems that we have not only today, but in the years upcoming. Using languages such as C#, and F#, we can apply these functional techniques today to help make your code more concise. But, with any paradigm shift, there are traps. Learn of some of the pitfalls you may fall into and how to avoid them.

Pull, Don’t Push: Lean Systems and Kanban

Dave Laribee

Full description forthcoming. I will say this will be aimed at getting you up and running with an iteration-less pull system or "Kanban." We'll cover some of the principles of Lean Software Development, queue and buffer patterns, and metrics/reporting.

Driving Toward the Goal: Standard Work in Software Development

Jef Newsom

Kent Beck titled his first book on XP "Extreme Programming: Embrace Change." Yet so many organizations and individuals that adopt agile software development practices only attempt to embrace the ongoing change of requirements, not the ongoing change of themselves and their processes. Because of this, so many teams who approach agile software adoption either plateau or backslide into a rebranded status quo. To truly become agile--to truly embrace change--we must focus on constantly improving our people, our products, and our processes.

To determine whether we are improving, we need both an understanding of where we are and to where we want to head. Taiichi Ohno is quoted to have said, "Where there is no standard there can be no kaizen." This notion of "standard work" is key to how the production workers in the Toyota Production System continuously improve the repetitive tasks of manufacturing. And this standard work is not a static "best practice" that we adopt to magically reach nirvana. It is a detailed description of how we currently know to best perform the repetitive tasks, along with examples of both desired outcomes and common defects. We will explore two common "Best Practices" for agile development: TDD/BDD and User Stories. We'll define our standard work, execute it, decide what works and what needs improving, and determine how we'll take action. We'll look for challenges, undesirable effects that are introduced, and we'll think logically about how we can remove them, experiment, and improve our standard.

By the end of this workshop, you will have shared and learned how others in the workshop are best applying practices like user stories and TDD. You will have shared what you struggle with and learned what others struggle with in applying the practices. You will "stop the line," come up with experiments for improving the approaches, try them out, establish a new standard, and continue improving. We'll explore common questions such as: how to identify the right user stories; how best to split user stories and still deliver value; how and where to get started when doing TDD. And we'll explore powerful tools such as: standard work; "stop the line" issue resolution’ TOC's thinking processes

Bring a laptop and your intuition.

All About MEF (the Managed Extensibility Framework)

Glenn Block

Today, it is difficult for applications and frameworks to meet an open-ended set of needs. Building in extensibility allows third-party customization, however there are many challenges in doing so. The application developer is often faced with creating an extensibility mechanism from scratch. This forces the extender to learn a new extensibility model for each application he extends. The design of the extensibility APIs directly impacts the ability of the extender to do what he wants. The Managed Extensibility Framework (MEF) is a new extensibility model in the .NET framework that addresses many of these problems. It provides as simple declarative model for application developers and extenders. The model itself can be enhanced to support your own semantics. It focuses on discoverability and composition, drawing from lessons learned from the DI (Dependency Injection) community although it is not a traditional DI container.

In this workshop we’ll start with the basics of what MEF is and how you use it. Then we’ll peel back the covers and go deeper into more advanced usages of MEF. Along the way we’ll also look at how MEF compares to DI/IoC containers, and how it fares with TDD and other agile practices.

We’ll come out of the session having built an application from scratch that uses MEF.

Textual DSLs in Boo

Ayende Rahien

Domain Specific Language is not just the DSL SDK from Microsoft. A DSL can make working with the domain much easier, since you are capable of leveraging the domain concepts directly. The other alternative to a DSL is an XML file, and we all know how well declarative model can work when you need imperative concepts, just consider NAnt for a minute and you will see the issue. Usually, writing a DSL in .NET would be a complex issue, requiring writing a parser, interpreter, etc. Boo already handles all of that, and its open architecture means that it is very easy to extend it to express the concepts of the domain. This talk will show you how to build DSLs in Boo and how to utilize this power in your applications.

DDD Chalk Talk

Dave Laribee and Greg Young

Full description forthcoming. Greg *might* make it, still up in the air. This will be a looser and more interactive workshop for all skill levels, but will focus on techniques for implementing rich domain models for .NET. Audience participation is highly encouraged!

Transitioning from NAnt to Rake

Dave Laribee — Fri, 17 Oct 2008 19:05:00 GMT

Maybe you're interested in this Rake business. Maybe you've got a big investment in a whole build infrastructure in NAnt. Maybe, just maybe, it's impractical to convert the whole enchilada over at once. What do you do?

Wrap it in Rakey goodness, of course!

Step one: leave your nant build in place. Write a little ruby function to fake call into Nant from Rake.

Step two: create your rakefile.rb (or rakefile).

Step three: incrementally replace NAnt tasks with Rake equivalents. Start simple...

Step four: evolve as necessary and on your own timeline!

VersionOne, Day Zero

Dave Laribee — Fri, 03 Oct 2008 03:50:00 GMT

I announced this on Twitter a while back, but I've left my full-time job at Xclaim to join VersionOne as their internal Agile Development Coach.

I'll say, leaving Xclaim was kind of a bittersweet thing. I'm still a part owner of the business, which is nice, but it's the excellent team and practice we've forged together that I'll miss the most. I get really involved in my work and it was at 5:00pm on my final Friday that I was feeling, let's say, like the ultimate chicken.

I'm comforted, however, by the fact that Xclaim goes on and continues to be a great team. Every coach needs a captain, and my colleague, Rik Bardrof, is more than ready to take on the next set of challenges. He's in cahoots with the same awesome and dedicated people I had the pleasure of working with over the years and I'm positive they'll continue to kick it, as they say, up a notch.

For those that don't know, VersionOne makes tools for Agile teams and organizations. In fact Xclaim is a happy customer. My job there, as the internal coach to their development team, is to drive new practices and process improvements that can help take them to the next level. What's cool is that they've got an already-rocking team right now. In the course of a day long interview/visit, I got a sense of clear vision from top leadership and met some very talented, passionate team members. All the ingredients for a legendary team are in place and that's something I knew I had to be a part of.

I took the job for another big reason: the domain is really interesting. You're working to drive continuous improvement on an Agile team working on a product for other Agile teams. How meta can you get?! I quite like the challenge of serving both domain expert and playing coach roles simultaneously. This team will push the edge of Agile and Lean to the point where we can harvest and validate innovations and bake them into a product that sells itself. This has to be the highest form of technical excellence a product team can achieve. I believe that's within reach, and am looking forward to sharing our experiences along the way.

.NET: Coming to a Cloud Near You

Dave Laribee — Thu, 02 Oct 2008 01:26:00 GMT

I was very happy to hear the news that Amazon will be providing Windows/SQL support on their EC2 cloud computing service. From the email announcement:

We are excited to let you know that Amazon Elastic Compute Cloud (Amazon EC2) will offer you the ability to run Microsoft Windows Server or Microsoft SQL Server starting later this Fall. Today, you can choose from a variety of Unix-based operating systems, and soon you will be able to configure your instances to run the Windows Server operating system. In addition, you will be able to use SQL Server as another option within Amazon EC2 for running relational databases.

I've been waiting for this option. For a long time the LAMP stack has held a distinct (and unarguable) advantage in long tail plays; much easier to find the kinds of virtual, on-demand models associated with "cloud computing." With this, I see that gap narrowing.

Even so, during this time of low availability, new architectures might have had a chance to sneak into the (at times monolithic) .NET developer community. When we reach for a persistence solution for our next killer web apps will it be SQL Server 2008 or a distributed hashtable?

Done For Real

Dave Laribee — Fri, 26 Sep 2008 16:03:00 GMT

I had the good fortune to sit in on a day long session with Dave Hussman (who is awesome, by the way) on the topic Agile coaching as a lead in to the Atlanta APLN meeting. It was chock full of tips and I recommend getting out to see Dave if and when you get the chance; he packs a lot of knowledge into a short amount of time in an extremely entertaining way.

One of the questions he asked is: when is a feature done? This is a perennial topic with Agilists and it's a very valid question; how do we know when a feature is "potentially shippable?"

I piped up with my answer: a story is done when it's in production use. That was a little different than the answers from the others in the room.

Think about it: we're not delivering value until that value has been delivered. That's a very Yogi Berra way of saying that until the user's using, that feature you made isn't contributing to business value. In a way that's one of the original premises of Agile: release early, release often.

This is the reason why I like the cycle time measure over the velocity measure. Cycle time tells us how long the feature took from the time it was green lit to the time it went into production. This gives us a real measure of how long it takes to deliver business value. Velocity simply tells us how long a feature took to develop (unless, of course, we have release-per-iteration)

Agile asked us to work better as software development teams and deliver in tiny little batches. Lean asks us to do the same thing, but put the software team in the context of the larger organization and from the customer perspective. Think globally, act locally. Doesn't matter how rockin' a development team is, if those features are being held in inventory until waiting for some deployment event, they're not done; they're only done as far as you're concerned, and, last I checked, there were more than developers and testers involved in the process of delivering software.

Laribee's Final Law of Continuous Integration

Dave Laribee — Tue, 23 Sep 2008 00:48:00 GMT

Seeing that DJ Miller is spinning up some amusing-but-true laws of continuous integration, I'm gonna weigh in and declare Laribee's Final Law of Continuous Integration. I see it as so critical that I'm going to put it quasi-biblical speak and in a blockquote:

Thou shalt not leave the office before the successful build of thine last commit. Doing so is beyond uncool and shall impose as a penalty, at minimum, the collective stink eye of the team to be cast upon thee.

Or maybe we'll go with modern and more direct version.

Stick around and make sure your last commit doesn't break the build.

More General Thing Madness

Dave Laribee — Tue, 23 Sep 2008 00:24:00 GMT

This description of problem analysis by Reginald Braithwaite (who is a smart person) struck a chord with me:

I found this to be an important point in my own programming, and I don't know if that's a general point but quite often we see something and we are very tempted to say "Oh, this is a special case of a more general thing", and then we solve the general thing. However that is an infinite recursion, it's always the special case of something more general. And if you are always climbing up the tree into the more general thing you will eventually wind up with a PhD in computer science and no code.

I know one of the areas that I get into trouble sometimes is when I try to make something too meta, too flexible. One of the things we abandoned early on at Xclaim was a very flexible party/roles management system that was so general -- it would have modeled anything -- but it was nigh impossible to represent in as a consistent and meaningful user experience and programming interface (developer experience). I try to stay more mindful, as an applications guy, of my abstractions now and root them in the concrete problem.

For me, learning and flexing DDD was a really useful approach for all sorts of domains and reigning in my tendency to get too abstract. As a method, you can apply it (in part, at least) to really any domain: vertical or horizontal. Patterns such as bounded contexts, intention revealing interfaces, the core pattern language, and ubiquitous language can keep you from falling into the pit of meta-meta-meta-madness.