the ‘bee log

http://xp123.com/xplor/xp0512/index.shtml

Good article about patterns for splitting user stories into more consumable chunks.

Consider:

If you use FitNesse without using JUnit or NUnit to test-drive and refactor your code… [fitness.org]

Now: I realize FitNesse is about the acceptance test, but this pull-out makes me wonder if there isn’t something between TDD and disciplined unit testing. The term “test-drive” better describes the style I am favoring these days.

Sometimes it is impractical to drive design wholly through testing… likely. Should each unit-of-work (backlog item, user story) have a cooresponding test asset (suite, test) before it can be considered complete? I think so, yes.

Marketing Strategy Pyramids one perspective on marketing a conceptual sell.

One of the chief problems the community has with DataSets is that they’re not as easily composable (flexible) as domain models. That is, they represent tables, rows, columns, and not what you’d want in a “pure” OO design: graphs-by-purpose.

So is every object graph a dataset? Is every table a class? Is every row an object? Is every column a property? Hardly… Does DataBinding save a lot of code? Does a typed DataSet provide a rich and stabile structure for you to program against for minimal effort? Absolutely…

What we’re seeing emerge in our codebase is a sensible approach. We have domain objects. We have datasets. Sometimes we have datasets that bear a relationship to each other.

The state model of CAB buys us composition and reduces the amount of code we have to feed and take care of. It lets us build up a “state collection” that may contain domain objects (AttributeMetadata), DataSets, primitive types, GUID values, anything. This is a state model metaphor easily comparable to ASP.NET’s HttpSession… a model that has its dangers, but is pretty convenient. The technical risks associated with this model are somewhat diminished considering the application is single-user (smart client) and can mitagated by developing guidance around the use of constants and generalzing WorkItem lifecycle management through a common WorkItemExtension.

Of course, WorkItem state is injected into child workitems. You need to be intentional about our WorkItem hierarchy and where the state is set. Something we’re discovering very early on.