the 'bee log

Hallway Conversations

Dave Laribee — Fri, 25 Apr 2008 15:03:00 GMT

One of the cool things about ALT.NET events and Open Spaces in general is that you encounter interesting hallway conversations at every turn.

Take this video as a good example. We've got Udi Dahan, Chad Myers, and ScottGu discussing issues around Microsoft and Open Source from varying perspectives.

How can conversations like this not lead to shared understanding when we multiply this conversation by a hundred or thousand times?

Audio/Podcast Help!

Dave Laribee — Thu, 24 Apr 2008 21:48:00 GMT

File this one under housekeeping and crowd-sourcing.

Troy DeMonbreun asks in a comment on one of my video posts:

Will there be an MP3 version available -- for those that like to listen on work commutes?

Great idea and I'm totally up for it. My concern is that the audio quality is pretty poor. That and I don't know where to host this stuff. Can anyone recommend a simple (key) audio cleaning tool? Does such a thing exist? Where is a good place to host an audio that produces an RSS feed so I can syndicate this easily?

If you wouldn't mind, leave a comment below! Thanks very much in advance.

John Lam on IronRuby

Dave Laribee — Thu, 24 Apr 2008 19:23:00 GMT

Time for another salvo of moving pictures!

John catches us up on the IronRuby and shows some under-the-covers architecture of the DLR at the ALT.NET Open Spaces, Seattle event. I didn't get the whole thing, but there's some good stuff especially for folks that may have fallen out of touch with the project.

So, yeah, get to commitin', cowboy!

Future Architectures Fishbowl

Dave Laribee — Thu, 24 Apr 2008 01:37:00 GMT

Greg Young convened an interesting fishbowl about moving architectures into the future. A number of "-ilities" are brought up in the course of this varied and good discussion.

Watching this I wonder if there is an architectural future or if it's the case that we're only in the ever-extending now. Messaging systems are a very old concept. Domain models and object systems are old concepts. Maybe the synthesis of these concepts are new ideas. Maybe it just takes a load of experience and knowledge...

What can we do to make our architectures more flexible?

I went with a higher resolution this time. It was a pain in the @$$ but downloads should be higher quality and full screen seems to be a better experience. Next up: part (only got the first 1/3, it's good though) of John Lam's IronRuby chat!

Polyglot Programmer Fishbowl

Dave Laribee — Tue, 22 Apr 2008 21:54:00 GMT

I recorded the Polyglot Programmer Fishbowl opening session from ALT.NET Open Spaces, Seattle last weekend. It's pretty interesting with a variety of well-known 'glots weighing in. Ted Neward, Charlie Calvert, and our very own Jeremy Miller open the discussion with a definition.

Personally, I'm a big believer in this Polyglot Future. I think, not uncommonly, we're facing a reality where we'll need one trusty language from each paradigm (static, dynamic, functional, etc.) with a number of DSLs internal and external.

I have a ton of video. These things take a long time to upload and encode and I'm a video novice so you'll see things trickle out over a few days.

Oh! I'd love any feedback as I'm trending toward more video content lately. Should I invest more time here? What can I change? Should I get a Steady-Cam®?

Iterations vs. Flow

Dave Laribee — Tue, 22 Apr 2008 18:15:00 GMT

I'm drilling pretty deeply into Lean these days. Scott Bellware turned me on to some of the more primary sources about lean manufacturing (Ben Scheirman does a good job of summarizing these books based on a recent conversation at ALT.NET). Since then we've had a bit of an "asynchronous book club" conversation in voice chat forms.

One of the ideas that's starting to crystallize is that we're not treating iterations appropriately. There's too much emphasis on "weekly" or "bi-weekly" work cycles. In DDD terms we're treating iterations as an entity when, in reality, iterations or sprints are better modeled as value objects.

Ok, here's a story for you:

As a product owner, I want to see the team's velocity over any arbitrary time range, so that I can see how many features a team can deliver in the future.

or...

As a product owner, I want to compare the velocity of any two time ranges, so that I can determine if our velocity is increasing because it should.

So why just the same time range every week? It's a bitch to have to content with time off and federal holidays. And, sure, I know you can't treat any individual iteration's velocity as reliable as velocity is more a trendline over a number of successive iterations, but it seems arbitrary to me that we'd lock the iteration down. We're back to a batch and queue mentality and the batches only get bigger when we move up to the release level.

Lean would have us pursue the concept of "flow." That is, we want a single part or component (analog in software: feature/story) to flow through the system continuously. The customer pulls this feature via priority, developers pull the feature via backlog, testers pull the feature via "development complete," etc. Right now customers can only truly pull at the release level. Now it's true that you can modify a release but keep a known schedule with a reliable average velocity and a fixed set of points (swap out stories that are stale, etc.), but this seems more than a little anathemas to the competitive advantages purported by a lean approach: chiefly a competitive advantage in demand satisfaction.

I'd love for us to pursue the concept of "feature = release." Truth is we're a bit far off from this vision. A number of issues quickly crop up:

How can customers cope with regular (say weekly) releases?
How do we structure our teams in this world view?
How do we get around the need to deliver a minimal set of functionality?
How does this work with "the big rewrite" as there's just a ton of features that need to be done for acceptable parity?

As far as #3 and #4 go, I think we need to challenge the scope of projects. When working in a rewrite or brownfield scenario, maybe we should get creative about introducing an anti-corruption layer and pinching off areas of improvement as services rather than waiting for the whole thing to be finished. We can also, in a rewrite situation, create an acceptance environment where the customer team can use the application. This is exactly what we're doing at Xclaim (where we're doing "the big rewrite" slowly) and it takes some upfront thought (more on that later), but the approach certainly works.

When we start thinking of features as releases we might need to dig a little deeper and find a solution that marries the desire to release early and often with the realities of a tidal wave of new software delivered regularly. I'm keeping an eye on things like SOA and Composite Applications and OSGi as a means of hitting this goal in enterprise software. I think it goes quite a bit deeper, though. For example, how are users going to cope with new menu items / screens / options / etc. on a regular basis.

First you'll need an environment, an assembly line, that permits fast introduction of new features. This assembly line will need to allow customers to "mix-and-match" the features delivered so they can determine when and how to release. The user experience will also need strong consideration. We'll need to find UI metaphors that lend themselves to consistency and discoverability. The bar for this is much, much higher than a product with, say, quarterly releases.

Like anything in Lean or Agile it'll take a village and a whole lot of cohesive thoughts. I'll have more to say on this subject as this idea of "flow" is leading me down the path of segmenting product design from feature delivery. This is a slippery slope with pitfalls of BDUF accusation waiting around every corner, so I'll appreciate a little patience as I experiment and theorize about these ideas.

Is anyone out there truly doing single part flow on their project? Anyone doing release-per-feature or even release-per-iteration? How long are your average releases?

Metastones

Dave Laribee — Tue, 22 Apr 2008 15:03:00 GMT

A ridiculous game that was created during the MVP Summit and ALT.NET Open Spaces, Seattle. Is Metastones the new Werewolf? Only you can decide.

I captured a lot of video during my brief, 7-day time in Seattle/Redmond. I promise to be back with some serious stuff in a bit.

Early Tool Theory

Dave Laribee — Fri, 04 Apr 2008 01:38:00 GMT

I got into a series of interesting conversations with the usual suspects, Austin edition, about tools. I wouldn't say we covered what I'm about to outline here in totality; these snippets are only starting to coalesce and firm up in my mind.

What's a Tool?

It seems to me that a tool can start out as a thought construct, an observation leading to a human activity or operation. A practice, such as BDD, is a tool driven from a value system (quality, efficiency, etc.) that may manifest itself in a "hard" tool such as RSpec or NBehave. The hard tools are often used to streamline and satisfy an entire practice.

Lean Manufacturing calls these tools "monuments." That might not be a totally fair comparison, but I hope we can agree that you can install a practice tool (such as BDD) with a series of smaller hard tools such as MBUnit/NUnit/xUnit.NET, NCover, and a nice base class.

Lean has a very negative view on these monster tools, or monuments, because they create waste. The concept "right-sizing" is used by lean people to indicate that a tool should be exactly the size needed to allow a part or product to flow through a cell that adds value. How can you right-size a monster? You can't.

This leads me to question whether or not the tools we're using or developing aren't just the right size. I'm certainly looking at what we're doing at Xclaim with a critical eye. I'll say that we use small tools (e.g. we're not using NBehave) that are assembled/automated with a larger substrate (NAnt). The more I learn about the benefits of lean, the more I'm not into the bells-and-whistles approach to software tooling.

One Tool to Rule Them All

Why are we pursuing this IDE business? Ok, ok, so they make good "product." And, yeah, sure, I understand the powers of static analysis now we can have an HUD hovering over our code giving us some quasi-futuristic view on the code we're writing.

Snowcrash IDE anyone? This is a vision that appeals to the science fiction reader in me, but I think we might be off on a bit of a fool's errand here. Let's get pragmatic, shall we?

We have a perfect substrate for integrating a series of small tools: the command line. No doubt when working with C# or Java it's nice to have refactoring and analysis support in our editor, but it's an editor folks. Too much focus is put on making this our only touch point, our only tool in craft. It's as if some day in the not-too-distant future we'll boot right into Visual Studio. When that's the case there goes my flexibility. In this future on the .NET stack I have a single trickle into my value stream: Microsoft. Should I want to extend the value of that environment, I'll have to go VSIP or accept their tributary as input to my value stream. Limiting factors abound and I'm not bullish on the future of "value stream operator" as a tenable business model.

Tool Evolution

We should, as an industry, evolve focused tools (think: a surgeon's scalpel) from larger conceptual tools. NAnt or Rake are perfect examples. These are specific tools that "pull" (another lean idea) a larger tool of continuous integration into possibility. We'd of course need a version control tool to satisfy CI and we've got a number of those. Notice how there's not one thing doing it. Take note that Victronix doesn't have the "Swiss Army Knife: Surgical Edition" in their product line.

What's the advantage of this approach? Chiefly: we can tweak our production lines to product design. We can tailor our process to match the pain we feel and the quality/productivity demands we're after.

A tool should start large as a practice. A practice should satisfy a number of values. From there we should build/buy/introduce the necessary automation (and only the necessary automation) to satisfy a particular project. These small component tools should be flexible and easy to patch into a bespoke and context-driven orchestra aimed at eliminating wastes common to every or, key point coming up, unique to each project.

What's thrilling and cool about the right-sizing approach to tools is now you're better able to improve at the systemic level. I'm going to make damn sure, while keeping an open eye, I don't get suckered into software gadget culture.

Welcome to CodeBetter, Aaron and Jacob

Dave Laribee — Wed, 19 Mar 2008 15:41:00 GMT

I'm happy to announce that we've snagged up Aaron Jensen and Jacob Lewallen. You might know them from as "The Eleutian Guys" from their already-popular blog. You might also know them as the inventors of the AutoMockingContainer.

Then again you might not know them. If you don't, you really ought to.

I'd also like to make it clear that Jacob and Aaron will go by their individual names instead of "The Eleutian Guys," "The Eleutian Boys," "The Eluetian Squad," or "Los Hombres de Eleutian." We should now refer to them as Jacob or Aaron as context demands.

If you'd like to group them into a single entity, please use the term "smart bastards" henceforward.

Thank you.

An ALT.NET Media Blitz!

Dave Laribee — Sat, 15 Mar 2008 14:27:00 GMT

It's been a busy couple of weeks on the ALT.NET front. Here's the run-down:

Jeremy Miller has the back page of this month's MSDN magazine where he does a great job of describing ALT.NET and filling in some of the background for people that might be new to the idea. Oh, and, thanks for the shout out, Jeremy!

While at MIX08 I had the opportunity to sit down with Scott Hanselman and record an episode of Hanselminutes. It's episode #104 and it's available right now! We start the chat with a discussion of ALT.NET, typical meta-stuff such as what we're all about, the relationship to other movements like Agile, Web 2.0, and Open Source. It's nice how we ended up drilling into dependency injection containers one example of how principles (inversion of control) drive tools and technologies.

I was pleased with the outcome. Scott's an easy guy to talk to and obviously an experienced interviewer. Perhaps he should interview Mark Zuckerberg at next year's SxSW? ;)

At this point I'm turning most of my extra-curricular attention to getting everything in order for a great event in Seattle and making some requested refinements to the community site at http://altdotnet.org/. If you have any suggestions or ideas for either I'd love to hear them. Email me (my last name at gmail) or get a conversation going on Twitter, http://twitter.com/laribee.

Mapping BDD

Dave Laribee — Wed, 12 Mar 2008 02:41:00 GMT

In my last post I offered a concise snapshot of how I'm practicing Behavior-Driven Development. Based on feedback, it was probably a little too concise and meta to provide any kind of valuable takeaways or discussion points, so I'm going to unpack what I said there over a few, more-specific posts.

Iteration I/O

I've experienced success with BDD as an integrated component of a larger suite of Agile practices. Specifically I see BDD as a mapping activity between user stories and code. Think of an iteration or sprint as a pipeline: you put stories in at the beginning and the necessary code comes out at the end. The BDD process starts before you put stories into an iteration; you provide acceptance criteria (in many forms, more on that later) in order to understand the nature and implications of the story. These acceptance criteria then serve as a context for the developer in modifying a codebase.

To be clear: specifications describe code and a developer specifies the code.

Think of story structure, in this light, as an aggregate root. One story has zero-or-more acceptance criteria. Acceptance criteria come in many flavors. Falling back on the object oriented metaphor we can say that a specialization (or subclass) of a criterion is a "User Interface Prototype." We can define another specialization as the "Scenario."

Now we're all probably familiar with these scenarios. They're the ones given in Dan North's introduction (and many others), something like:

After depositing $100 dollars into an Account with a balance of $0, the balance should be $100.

Sidebar: you'll note that I'm not a big fan of the Given/When/Expect formalism or even the less restrictive when/then format. Story scenarios should read like Plain Old English (POE). Well maybe not plain OLD ENGLISH: whence ye olde account hath taken deposit.

I'd contend that these are bad examples, the plague of our industry. You might find this exact scenario appear in an executable class specification several times. It might surface as a specification of an Account entity in a model. It might also match a specification of a controller pattern in a presentation layer. Are the two the same? Nope. Would you express that surface duplicity in the story. Surely, no.

Furthermore we'll have a number of technical or infrastructure things we need to do. Our end user won't care about that. Sorry, you can try to make them, but they won't. They certainly won't author those specifications. It's up to the developer, when working on a story as a vertical slice through a system or through multiple components in a non-monolithic application to author specifications while working. The process of writing specifications continues past the process of estimation and admitting a story into an iteration.

So, yes, mapping is what we're doing here. Mapping and continually adding specifications. We're mapping specifications that came in to an iteration to things like the presentation layer and the domain model. We're developing specifications and subsequently mapping them to infrastructure bits to fulfill a complete, working feature and we constrain ourselves to just doing enough to make that feature "potentially shippable."

Define: "Behavior" and "Specification"

What exactly is a behavior? Is a behavior a feature? I vote no. I like to think of a behavior as the smallest possible expression of one (and only one) thing that a code artifact accomplishes. Sometimes that's a state change in a single object and sometimes that's a collaboration between multiple objects. Sometimes a behavior will be technical, sometimes domain-specific or business oriented.

Features, on the other hand, are closer to stories. A feature (not always, but usually) will require a family of behaviors be present to work. And not all features are created equally. Users tend to think of features as larger workflows. These larger features, epics or I've taken to calling them narratives, are sometimes a little big for a small, tight iteration so I try to break them down to the smallest possible story that's still readable, understandable, and able to be prioritized by an end user.

For me specifications describe behavior and behavior is a description of code: classes in an object system. It's a happy side-effect that sometimes our domain model behaviors mean something to an end user, but an Account entity with a fully functional deposit method does not a feature make.

Where's the value?

The flavor of BDD I'm talking about are class specifications. That's to say that I had the best outcome by trying to derive value from BDD on a technical front. We take a story, provide enough acceptance criteria in the form of scenarios to estimate, and use those scenarios to create executable specifications that prove our code's behavior.

It's a little software value chain.

The value from this process is tremendous. First we get our refactoring safety net. By having a well specified codebase we can make changes with aplomb. We now have a nice regression suite and we get all of the quality benefits of unit testing and the design discipline of TDD.

What sets BDD (and specifically this class specification style of BDD) apart from TDD or unit testing is the fact that our specifications are now documentation. The create a localized codebase that can be entered by any developer: we're closer to collective ownership. It does it in a way, however, where we can now start talking in a kind of mapping language. That mapping language involves both the ubiquitous language of the domain model(s) we have and the vocabulary around recipes a team will evolve for infrastructure ("oh, hey, use the Logger").

It's Not Over (Sorry)

This is a huge topic. I'm afraid I have more to say on the subject but in the interest of getting this out there I'm hitting the publish button. As a final sum-up, I'll say that in my experience class specifications are the way to go.

Viewing BDD in this light has immediate benefits. I'm not throwing out the possibility that executable acceptance tests, "story runners," or FIT-hybrids are a bad way to go, but I think they're much more toward research and development. Class specifications done in a BDD style are the real deal. They work in the hear and now, so that's where my enthusiasm and effort is directed.

I'll unpack my theories about story runners in a future post. I'll also talk a little bit about working vertically with BDD and this concept of Iteration I/O. We're trying a few new things at my company that should provide some empirical basis for how we're tackling questions around user documentation, acceptance testing, etc.

A Brief Statement on BDD

Dave Laribee — Mon, 10 Mar 2008 02:20:00 GMT

Scott Bellware posed a question on the newly formed BDD list asking people's background. The list is concerned with Behavior-Driven Development but seems to have a heavy bias toward the .NET developer. This bias seems to bend the conversation towards tools, where tools mean a kind of language/platform specific technique.

So, as a BDD user, what's my platform background?

In the near past I've been pretty much 100% C# on the CLR. Lately I have some contemporary work in RoR/RSpec and Python of the Iron variety.

My BDD world view on Sunday, March 9, 2008

I see specs as "class specifications" and behaviors are story/feature-to-code mappings that teeter on the line of business readability depending on the particular object collaboration they describe and, as such, are best expressed in the same language. This belief echoes that of the construction of virtual machines, see: the argument for Rubinius.

I think it's hard to talk about BDD in the abstract. Hard in the sense that, from the bottom up, it's hard to divorce BDD from the implementation as specifications, well, specify the implementation. For me, behaviors are provided by the code in response to how the stories modify a system's present state.

I think there's a flip-side of BDD that says iteration-level stories end up as some kind of executable specification. For me, this isn't a specification it's a feature. I tend to look at features as a larger expression of how a user approaches as system to accomplish a piece of work. In my experience it works well (on a certain class of business application) to divorce these expressions from the BDD process. We assemble stories on the opposite side of an iteration into a kind of sequential story or "narrative" that expresses an atomic or composite workflow.

Loose thoughts to be sure. While I'm always interested in growing and extending our practice, I'm finding this definition and set of constraints handy and successful in applying a BDD process across languages/platforms.

The Separated Interface Pattern

Dave Laribee — Fri, 29 Feb 2008 20:47:00 GMT

I did a quick streaming video today with the Separated Interface design pattern as our topic du jour. I wanted to see if the whiteboard would show up on video and if this was something people thought was valuable. It's certainly easy to pick a design pattern and talk about it fairly loosely with a few examples on the dry erase. It's a little shaky, so next time I'll try to keep the camera still and focused on the right thing.

The second installment is just a short introduction to two resources from Software Engineering Radio, a podcast I'm a big fan of that tackles issues in software architecture including languages, object systems, processes, patterns, etc. The first is an interview with one of the minds behind the Spring component framework, Juergen Hoeller, in which he talks about some strategies for managing large codebases. The second has the se-radio guys chatting about what components mean to a software architect, their main attributes, and conceptual design principles. Separated Interface is a key enabler in both topics when developing an object system.

The Ten-penny Tour of My Office

Dave Laribee — Thu, 28 Feb 2008 23:25:00 GMT

Brendan (Chief Nerd Herder at CodeBetter) sent me a nice little gadget, a Nokia N82 hooked up to the Qik video streaming service. With this I'll be able to assault various people at various events with the real-world questions you all deserve to see answered.

As a prototype I took a tour of my (messy) NYC office. That's right, folks, this is exactly the kind of high quality, in your face, take no prisoners journalism you can expect going forward! Take the tour, get on the bus, right here.

On a serious note, I'm taking this rig out to MIX08. If there's anyone you want me to hunt down, post a comment and I'll do my very best. I'll have the device for a week or two, so maybe there's some whiteboarding I can do for you all? I'm open to any and all ideas, let 'em fly. We need to fatten up the catalog of CodeBetter videos.

We'll be rotating the device in and out of the grubby paws of various CodeBetter blogger over the next few months as we roll out this fun little experience, so look for good things! You'll receive a twitter announcement from @codebetter right before we start taping (LIVE!) and you can join in the comments, etc. It's pretty cool, actually; the comments show right up on the handset so viewers can ask questions, be snarky, fire it up, all that.

Speaking and Conference Schedule

Dave Laribee — Wed, 27 Feb 2008 16:40:00 GMT

Things are loading up for 2008, so it's time for everyone's favorite "where I'll be over the next six months post."

Tonight (yeah, tonight) I'm going to be given a very early version of a new talk called Planned Agility?! at the Philly ALT.NET group. If you're in town, come on down. I'm hoping this will be more like a facilitated discussion with lots of feedback. I've been working on this as more of a seminar or class than a 70-90 minute stand-and-deliver kind of talk.

I see Philly is the ideal place to bring raw materials for this kind of thing as there's an unusually high Agile IQ there. Brian Donahue has a page up so you can read more there. ALT.NET events, in general, create a highly interactive expectation. I'm getting out there early with this one as I sharpen it to a fine point for DevTeach, Toronto.

I'm going to MIX08 next week. There's going to be an "open spaces" area that I'll be a part of and I'm looking forward to seeing what's happening with Silverlight and the DLR along with -- let's hope -- some fun, new surprises. If you're going, let's grab a cocktail, how about it?

Next up? Let's see. On April 8th I'm speaking at the Northern New Jersey User Group on Behavior-Driven Design. It's going to be an intro focused toward writing lean and mean class specifications. There will be some tool talk but it's going to be mostly focused on coming up with a workable solution using the AutoMockingContainer, a base class, and Rhino Mocks. Check out their event page for more details.

After that I'm headed to Seattle for an epic stay. Going to the MVP Summit (April 14-17) this year which should be fun.

I'm really looking forward to ALT.NET Open Spaces, Seattle on April 18-20th. Registration for that one is closed, but the list of participants is out of this world. I'm looking forward to a good mind stretch, meeting new people, and hanging out with some of the friends I've made over the last year-and-a-half.

The last thing on near-term radar is DevTeach Toronto on May 12-16th. I'm doing four sessions there:

BDD Installed - You'll know everything I know about BDD, theories, how we're practicing it at Xclaim, etc. Code focused
Planned Agility?! - How do we plan in an Agile context. It's both necessary and possible.
Agile Q&A with Friends - A reprise of the free-form, free-wheelin' fishbowl from Vancouver. Should be fun!
Strategic DDD - Ratcheting our discourse on Domain-Driven Design up a notch to talk about complex modeling issues, multiple models, etc. This is, at it's heart, a session for Agile Architects.

That's it in a nutshell. Scheming, cooking-up, and plotting a few other things that may or may not happen and I'll be sure to announce here if there's a change in plans. Come on out and get involved in the discussion! Looking forward to seeing some fresh faces out there (yeah, you!)...