Note that my RSS feed hasn’t changed (more on how I managed that later) so this announcement is really for friends, enemies, frenimies, and lost Googlers that come to laribee.com or thebeelog.com straight up.

Now back to your regularly scheduled program!

You know the idea. The Agile realm re-imagines the traditional manager as a sort of human amplifier. Let’s consider Scrum. One of the named roles in Scrum is the Scrum Master. It is the Scrum Master’s responsibility (among other things) to remove obstacles revealed by the team.

To be amplified you’ve got to leave yourself open to amplification. In our world - where we don’t have DARPA, Super-sonic Jets, or 30mm Cannon - this means responding to criticism. Learn how to take criticism, and don’t be afraid to get to the heart of the matter. Courage is one of the core XP values for a reason.

Oct 3 | Syracuse, NY | Syracuse .NET Developer’s Group

Rik Bardrof and I will be doing a spruced up variant of the You Got Served: Ping-Pong Pairing talk that covers TDD, DDD, and Ping Pong Pairing. If you’re in the cold north, you should try to make it. Rik, for the unaware, is a blogless developer who works with me at Xclaim. We should get a lot of opportunity to talk about some of the techniques we use in the wild.

Oct 5-7 | Austin, TX | ALT.NET Open Spaces Conference

The event of the year, IMHO. While not a speaking engagement (it’s more an invitation to a conversation, wait…) the event will be a great opportunity to meet many people with at least one foot in the .NET developer world. The event is in the Open Spaces style so I’ll pitch a few sessions and see how they’re received. In any case, I’m not going to bring stand-and-deliver sessions to this happening; I expect lots of conversation/debate/back-and-forth!

Oct 8-9 | Boston, MA | ReMIX

Giving a talk called Language Mashups with the DLR (it’s billed wrong on the site). Why would you use Javascript, Ruby, C#, Python, and friends all in the same application? What’s the DLR? How’s it work? What does stepping outside of the mono-langauge world do for you? Join me in Boston and find out.

Oct 12-13 | Nashville, TN | devLink

I’m speaking about the juicy goodness that is Domain-Driven Design and NHibernate. I’ve done this talk a few times now, so I’m retooling it going in to Music City USA. Should be a good time!

Oct 19-20 | Tulsa, OK, | Tulsa TechFest 2007

Enter the Ping-Pong Programming House of Pain with me and coconspirator Ray Lewallen. This session is so free-form, high participation, and different every time. We start with a model (DDD) and let it go from there. Hopefully we’ll be able to work in some developers from the peanut gallery like we did in OKC.

Nov 25-29 | Vancouver, BC, CA | DevTeach

Doing a number of talks here (DDD, User Stories, Agile Panel, check the site). There are a number of excellent speakers on the roster, so I’m not only honored to be speaking, but jazzed up to be able to attend sessions by such folks as Jeremy Miller, JP Boodhoo, Ayende Rahien, James Kovacs, Scott Bellware, etc. I’m also glad to finally see Vancouver; I hear it’s the kind of city you can immediately picture living in.

If you’re coming out to one or more of these events let’s meet up! To me, that’s the main value of doing this - meeting a number of interesting, new people and catching up with those I’ve already met on the road.

Luckily I’ve got one for you right here! Print it out and put it in your team room, tack it to your task board, and tape it to your monitor.

I made this about a year ago and put it up on the bulletin in our team room. From time to time a stakeholder will wander in, notice it, and ask about it. Then I say, “well let me tell you about this, it’s really exciting.” 

It’s a handy information radiator for everyone and an omni-present reminder of how we, as Agilists, stay on point.

In the end any program must manipulate state. A program that has no side-effects whatsoever is is a kind of black box, right? You press go, and it runs, and all you can tell is the box got hotter.

Check out the video of his talk on Haskell at OSCON 2007 for this and many other gems.

I couldn’t care less about hardware. I care about my experience — keyboard, mouse, video walls – but the internals — Intel, AMD, pico-hampsters running on pico-hampster-wheels – make absolutely no difference to me.

To me infrastructure is a dial tone. It needs to be there, respond to my request, and let me get to the stuff I care about with minimum hassle. I care about understanding a problem or opportunity and finding its most direct and elegant solution in software. Of course my workstation needs to be fast and usable. Of course it needs to be reliable. And, oh yeah, if it could look pretty, that’d be an extra bonus.

The developer uses tools to build tools. Software solutions, when delivered into the hands of the end user, are a tool. I build or acquire tools that help me build another tool. There’s a lot to figure out and grok. Throw in our industries frenetic rate of change and there’s plenty to keep me busy for several lifetimes.

Okay. That’s kind of a who’s on first way of saying the craft of developing software is generative: tools produce tools produce tools. Wouldn’t my time be better spent learning and mastering other elements of pure thought stuff? New languages, frameworks, patterns, techniques, and (you guessed it) tools?

I crave the form and trust the details. Knowledge of hardware internals might possibly inform your craft, but an examination of history, art, architecture, city planning, philosophy, or psychology might inform in a more creative, less pseudo-comparative way. 

And before I hit publish, some disclaimers:

1. I would care about hardware if it were part of the problem domain I was making software, e.g. embedded systems, network monitoring, device drivers. As soon as I moved on, I’d stop caring.
2. I am very thankful that there are people that do care about hardware. Good network design/engineering/support (for example) is its own craft with its own horizon!

Perfection is a pervasive theme in the larger Agile community.  Scott Bellware makes an agreeable point saying we should focus on the verb, not the noun; Dave Nicolette has a pragmatic take on adoption of Agile methods; Alistair Cockburn brought the term Shuhari to the Agile vernacular.

I have in my mind’s eye a particular scene from The Last Samurai. At one point the camera pans over a rural village where the town’s folk are engaged in their various activities of daily living. Captain Algren observes:

From the moment they wake, they devote themselves to the perfection of whatever they pursue — I have never seen such discipline.

Is the action is the actor’s raison d’être? Yes, but there’s more to it than one person and their craft. There’s an interdependence between the villagers. The group dynamic creates an environment of healthy peer pressure that ingrains, supports, and reinforces the discipline required to pursue perfection. I depend on my neighbor, a potter, for my earthenware. My neighbor depends on me, a farmer, for my vegetables.

Committing to the Agile way is a decision to pursue perfection. Discipline is flat-out, straight-up, and without a doubt the most fundamental ingredient in advancing on the path. Everyone involved in an Agile project or organization needs to hold discipline up as a precondition to continuous improvement. Customers, developers, managers, executives… everyone. Improve your craft, exercise self-discipline, and expect your team to do the same.

In the commercial a boy approaches an owl, Mr. Owl to you, with a question: “how many licks does it take to get to the center of a Tootsie Pop?” Ever the empiricist, Mr. Owl engages in a short experiment. Loosing his discipline after three licks the owl bites into the candy’s chewy, pseudo-chocolate inner core. The owl licked thrice before chewing. He asserts, therefore, it takes but three bites to get to the center. The boy seems dissatisfied with the conclusion of Mr. Owl’s investigation worriedly observing that ”the world may never know.”

The number of objects you need to represent a real world entity can vary greatly depending on the needs and architecture (which should be driven by the needs) of your application. I’m still a believer in one entity probably isn’t enough. Let’s introduce an example. Say we have to represent Customer somewhere in the application.

My first question is what makes up the Customer? Likely they’ll have one or two address objects? Let’s say they have two, a shipping address and an office address. So far we’re up to “thu-ree” - as Mr. Owl says - objects. Customer in this sense is a composite or, in DDD terms, an aggregate root. So right we’ve got (potentially) an effective infinite number of “objects”. Let’s make “object” mean “type” or “class” going forward. If we recast the question as “how many types does it take to represent a real world object” we can come up with a finite number of associations be they many-to-one, many-to-many (association class), or one-to-many (collections). Still I like the idea of “Customer as boundary” that comes with the DDD notion of aggregate root.

So how do we get that Customer to our application layer? Generally speaking I look for an organizing principle (information architecture) centered on the main entities of the application. I like to group screens and actions in the UI around the entity. So I’d like to come up with a screen that lets you act on a list of Customers or open an individual customers, browse its data and take action on that instance of customer. Even though there’s a certain nakedness to these business objects I tend to favor creating DTOs or messages that represent the required slice of data. For example, I’d consider a list-like DTO of Customers that’s contains data that helps you find an individual Customer represented by a more jagged, higher resolution detail DTO. I also don’t invest too much time in factoring my DTOs for re-use, so I’m apt to create a DTO specific to the purpose at hand. 

Sidebar: I use a base class and external DSL for data transfer objects and have them support data-binding. Read more about it. I know CSLA, for example, goes with a kind of single entity approach. Rocky calls it “mobile objects.” That is a customer is a customer is a customer. I don’t like this because I feel that it creates a lot of transformation code everywhere and I like to centralize this in a Service Layer. I also avoid loading my entity classes with responsibilities orthogonal to business logic such as data-binding support. Instead I favor a Service Layer peopled with Application Services. An Application Service is really a facade to the Model layer that brings infrastructure (sending an email) in to the mix with Domain artifacts: Entities, Repositories, Factories, and Services.

Now we’ve got all these messages that support a user interacting with the model of a “real world object” and we’ve got a number of MVP triads that ultimately construct these messages that work on the entity. I guess my answer is as many as it takes and it can take quite a few. The benefit of splitting a real world object into a number of tailor-made (for the layer) objects is that it preserves a layered architecture which benefits through partitioning and isolation. That’s a Byzantine way of saying layers make a code base easier to evolve/maintain.

If I had to break it down to for my current default architecture for smart clients that work over a firewall:

1. Customer (Aggregate Root Entity)
2. Address (Value Object)
3. CustomerRepository (Finds/Saves/Deletes Customers)
4. PreferredCustomerService (Gets a list of Orders for a Customer and determines if they’re standard, gold, or silver)
5. CustomerService (CRUDdy Application Service for Customers)
6. CustomerDetail MVP Triad
7. CustomerSearch MVP Triad

All of these items are required to represent the real-world customer given my architecture. Even if you go directly to model you still need to display stuff. Even if you’re not using MVP and are using Autonomous View, it’s still another object required to “represent” the real-world concept of customer. My preference is simply to let the concept of “Business Entity” flow through a layered architecture when it’s natural to the end user. In general I think it is a natural concept for a lot of entities. Adjusters talk about working with claims; underwriters write, renew, and terminate policies; project managers manage, well, projects…

Having this baseline set of patterns helps you avoid the trap Mr. Owl fell in to. Namely, patterns control how many licks, um, objects it takes to get to the center of a user story and at the heart business value. You don’t need to go nuts with an over-arching, prescriptive framework. Pick a few design patterns to start with and a framework will emerge over time as you suit immediate needs, ease frequent pain points, and address redundancy. I, personally, look for how entities are treated, look to them (initially) for an organizing principle of user experience, and find design patterns that mesh my findings with a good measure of maintainability and testability.

]]> http://laribee.com/blog/2007/08/07/how-many-licks/feed/ http://laribee.com/blog/2007/08/06/one-logical-assertion-per-test/ http://laribee.com/blog/2007/08/06/one-logical-assertion-per-test/#comments Tue, 07 Aug 2007 02:15:03 +0000 Dave http://laribee.com/blog/2007/08/06/one-logical-assertion-per-test/ Having had the chance to get some good feedback from Aaron on my One Mock Per Test post I’m refining the TDD rules I’ll live by going forward.

I still believe tests should have a single assertion, but as Ayende points out occasionally a single call to Assert.ThisOrThat won’t cut it. What we really want to preserve a single logical assertion. Put another way, if a test has multiple assertions, each assertion must exhibit a high cohesion with the specification described by the test. In Ayende’s example each assertion has a shared mission: verify the contents of a row-like structure. The nature of the specification dictates more than one Assert. Without having to use too much imagination we can see in some circumstances it’d be overkill to check that each individual cell is set with a separate test, given that he’s working at the row level. I’ll pretend his specification says “a row is put in a certain state.”

An example test that uses multiple assertions in a highly cohesive manner:

[Test]
public void A_user_sees_results_of_a_gold_customer_search()
{
   ICustomerSearchService mockService
      = _mocks.DynamicMock<ISearchService>();

   ISearchView stubView
      = _mocks.Stub<ISearchView>();

   // puts 26 customer entries in a fake DTO
   CustomerSearchResultDTO fakeResults = GetFakeResults(26);

   using (_mocks.Record())
   {
       Expect
         .Call(mockService.FindCustomersByLevel(CustomerLevel.Gold))
         .Returns(fakeResults);
   }

   using (_mocks.Playback())
   {
      SearchPresenter presenter = new SearchPresenter(stubView, stubService);
      presenter.FindGoldCustomers();
      Assert.AreEqual("Gold Customers: 26", stubView.Title);
   }
}

In the example there are really three explicit, but highly cohesive, assertions in this contrived example:

1. I expect that ISearchView.FindCustomersByLevel will be called
2. ISearchView.FindCustomersByLevel will be given an enum argument CustomerLevel.Gold
3. The view (technically a stub) will have the title “Gold Customers: 26″

In the real world I’d likely treat the stubView as a mock object and set an expectation that it’s Data property receives the fakeResults. Another thing I’d probably do is stick with all interaction testing and treat stubView as a real mock object. I’d set an expectation that Title was set instead of asserting Title was set to a specific value after the fact. To me it’s a clear case of six to one, half-a-dozen to another but I suppose there’s something to be said for not paradigm shifting too much between interaction/state testing if it can be avoided.

However you cut it, these are highly cohesive assertions; they belong together and describe a complete interaction. The test is still satisfyingly small so I continue the benefit of quick return to test mode after passing green.

As an aside: I like Aaron and Jacob’s advice about using DynamicMocks (when using Rhino Mocks) as a way of building a more flexible refactoring/change safety net from your tests.