June 2009 Blog Posts
BDD beginner’s stumbling block

I should probably add that this is a stumbling block that *I’ve* run into, which doesn’t mean anyone else will.  But it is *my* blog, so that should be obvious.

I have started to use BDD on a greenfield project because I hate it.  Well, that’s not quite accurate (since it would be pretty dumb if that was the only rationale behind it).  I like a central idea behind it.  Well, I don’t hate it.  Anyway, the central idea is that you can write up specifications that are in more or less straightforward English, and using Machine.Specifications anyway, you get this nice, pretty (well, not really pretty, but legible) report that lists out which specifications have passed, which ones have not yet been implemented, and which ones fail.

What I’ve always hated about BDD is that the examples I’ve seen all try to force specifications into As either  a/I want/So that or Given/When/Then format.  It’s like trying to do software development through nursery rhymes.  “See Spot run.”  Even worse, it seemed as if you had to actually force all of your specification code to follow one of these formats.  For whatever reason, this always has rubbed me the wrong way.

Machine.specifications, at least in terms of how I’m using it in my ignorant neophyte manner, seems to allow a little bit greater flexibility in how you structure the language of the specifications.  Within the C# code, you still have to use the framework within its confines, and there’s that great ‘phallic symbol’ syntax you have to use, e.g., “= () =>”.  But it seems to be an improvement.

And, as BDD is supposed to do, it does help you to focus.  A business partner came up with a domain concept that was somewhat sophisticated (details irrelevant) and he described it by using examples.  Now, in the good old days of total BDUF, it would be natural to take the concept and then try to generalize it to all possible permutations as part of the design process.  But by focusing the specifications to test the examples given, you write the minimal code necessary to do so.  If another example comes along that ‘breaks the model’, you then have to refactor the already existing specifications.  Rinse and repeat.

But, one thing I’ve found myself doing in the initial stages, with specifications that I have designed as being a domain expert, is constantly renaming the specification classes so that the report is more legible.  Now, to a certain extent, this is part of the point.  As you clean up the language of the specifications, you may find yourself discovering that your specifications aren’t quite right.  And this, I think, is a good thing.

However, it also can lead to a lot of re-writing of the class names even if the assertions themselves stay the same.  You can spend a lot of time doing this.  At least, *I* can spend a lot of time doing this.

Hopefully, as I get more practice under my belt, this will lessen.

posted @ Saturday, June 27, 2009 7:41 PM | Feedback (2)
pmk – poor man’s kanban – 2 of N – Waste

At some point, one would think I would talk about, you know, kanban, specifically, the kanban board.  I’m getting to that.

But first, I want to talk about the concept of waste and how it fits in.

Now, within the Toyota Production System, the precursor of at least one version of Lean Software Development, there is a list of the 7 types of waste.  This immediately makes me skeptical.  Really?  7?  Not 6?  Not 8?  We’re all geeks here, don’t there have to be 42?  I don’t buy it.

Furthermore, as I mentioned in previous posts, the idea that there is only waste is, in my mind, obviously wrong.  When I joined the yahoo kanban group, I raised this point immediately by pointing out the difference between waste and cost as it applied to the food industry, using shrimp as an example (David Anderson hated this, but fine).  If you sell any dishes that have shrimp as a component, you have a food cost involved in buying the shrimp.  There is also a cost in preparing the shrimp.  These costs cannot be eliminated, thus it makes no sense *at all* to talk about eliminating waste.  If you buy shrimp and throw it out later, that’s waste, but in the normal process of operation, you have a cost.  This cost should be minimized, at all costs (pun) but it cannot be eliminated.

I think this applies to software development as well.  There is waste (which should be eliminated) and there is cost (which should be minimized).  Conflating the two is a horribly bad idea.

Having said all that, I think that the notion of waste is something that is very easy to understand within software development, and is a concept that *finally* makes clear why agile methods of software development can be superior.

But to explain this best, let me use an *entirely* hypothetical example, an example that we shall call “The Company.”

The Company

<conversation between Joe, John, and Alan at the Company…they are all developers, but savvy ones>

Joe: What is your estimate of the amount of time that we actually spend writing code, either code to implement new features or code to fix existing defects?

Alan: I’d say it was about 5%.

John: You’re kidding.

Alan: Well, I guess that might be a little low.

John: No, I was thinking it was more around 1%.

Joe: Do the math.  You think you spend only 24 minutes a week on productive work?

John: Hmm, yeah I guess there was that month where we were implementing that major module re-write…

Joe: Throws the entire average off.

John:  Right.  Okay, I’m going to go out on a limb and say that 10% is about right.

Joe: When I was working at a start-up, I think we spent at least 80% of our time actively writing productive code.

John: Yeah, I think it was closer to 90% for me…Want to go grab a coffee?

Alan: Is that going to affect the numbers?

The Company has a very specific project planning methodology in place.  It does what it does.

The group that talks to the customers is called Product.  They are the only group that is allowed to talk to customers.

Product manages a ‘backlog’ of sorts that includes customer requests, along with known defects that are tracked in an internal system, which are ranked by priority.  Calling it a backlog is probably a bit misleading.  What actually exists is multiple lists of things that need to be worked on, and Product consolidates these lists and decides what needs to be worked on next.

For defects, Developers are asked to determine root cause, and if it requires any design work or just a simple fix.  If it requires just a simple fix, then developers are asked to give a rough estimate of how long it will take to fix.  If it requires more, the need for a design arises.

Things that require any design go down a different path.  Particularly, if Product decides that certain items are of top priority, they get passed to the Design team (not to be confused with UI design) and BA team.  They then start to determine exactly what might need to be done.  This includes UI changes, code changes, and anything else.

This is obviously true of enhancements, which come from customer requests.  Product works with the customers to get requirements, and then works with the BA team to start to develop more detailed requirements.

The design team works with Product through the BA team to come up with what actually has to be done, UI changes, code changes, etc.

As the design team does its work, it needs to record estimates of how much effort it will take to complete the tasks it identifies.

Once the design team is done with its work, it then passes on the actual work (as recorded in documentation) to the build team.  Sometimes,the members of the build team have been involved in the design process, but this is rare.  Usually, the build team is given a set of documentation that tells them what they need to do to.

As this process goes on, the QA team works with the BA team to construct the tests they need to run.  These are based off of the initial requirements.

As the developers get the design documents from the Design team, they begin to implement the required changes.  As those changes get implemented, they then need to be migrated to the various environments of the Company.  Dev/Testing/Staging/Whatever.  At each step, manual changes are needed to make sure the migrations happen successfully.

As defects are found, the developers work to fix them, but those fixes then need to pass through the various environments, Dev/Testing/Staging/Whatever, so there is a lag between when the defects are supposedly fixed, and when those fixes are verified by the QA team.

To make things really fun, imagine that there are multiple code bases, multiple streams, where code developed in one base has to be inevitably merged into a different stream, often at times significantly different from when they were originally worked upon.

Waste – Can we count the ways?

Now, as I’ve mentioned previously, the notion of waste runs up against the notion of cost.  There is always a cost of getting requirements, doing design, doing development, testing the work of the developers, and moving code between environments.  Even in the best of situations, there is always going to be some cost.

But what I think Kanban/Lean/Pull/Whatever does is highlight the notion of waste, and especially the notion of TIME wasted.  The waste of Product managing the multiple lists of things to be worked on.  The waste of co-ordination between Product and the Designers as they work on the various items.  The waste of having developers who weren’t part of the Design process having to ask for clarification from the Designers when questions arise (since the documentation they are given is always incomplete), especially if the Developers cannot directly engage Product of the BA team.  The waste of the QA team having to wait for the developers to complete their tasks before they are able to begin their own testing.  The waste of moving code between environments involving those manual steps, where being manual, they almost guarantee mistakes, even with the best of teams.  The waste of having fixes made by the developers which can’t be tested for a certain period of time until it gets deployed at a fixed date in the future.

And the list goes on and on.  My *entirely* hypothetical example describes things to the extreme, but there are parts of it that I think most any experienced IT professional can relate to.  Large pieces of work are broken down into supposedly manageable pieces, but these pieces move through the system in almost unmanageable blocks, all in the name of manageability.  At almost every step, time is wasted waiting on some other step.  QA waits for deployment which waits for development which waits for Design which waits for Product.

So, what can we do?

Needless to say, pointing out the flaws in software development, while fun, is somewhat easy.  What is more difficult is coming up with ways of making things better.

Kanban/Lean/Pull/Whatever doesn’t promise to fix everything (and anyone who suggests it does is lying or selling snake oil).  But, it does have ways of potentially improving these things, or at the very least, highlighting exactly where and when waste occurs.  In the next few posts, I hope to describe how this is so.

posted @ Monday, June 22, 2009 2:37 AM | Feedback (2)
Stanley Cup Champions 2009 – Pittsburgh Penguins

What a magnificent end to a crazy season.

Maxime f’ing Talbot.

During a season where the Pens played some of the worst hockey imaginable, where they had to fire their coach mid-season (a move that never works) after a horrible game in Toronto, going down 2-0 in two series, having an at time horrendous power play, a goalie giving up incredously soft goals, with their star and captain going out due to injury in a Game 7 on the road (where no one had won since 1971), the Pens did it.

I have never been so happy to be so wrong.

The season started off badly, with the loss of a bunch of talent and an injury to their best defenseman.  When Hossa signed with Detroit at lesser money, many Pens’ fans were outraged, but, to be honest, his explanation made sense.  He had a better chance at winning the cup with Detroit.

Then after a decent start, the team started to stumble.  A team with Crosby and Malkin…you wouldn’t think they couldn’t score, but they couldn’t score.  Fleury showed signs of brilliance, but was uneven, and gave up the odd goal when trying to play the puck.  Finally, in what seemed a move of total desperation, they fired the coach and brought in Bylsma from the minors.  There was no way this would work.

Then they went on the streak that got them to the playoffs, even getting home ice against the Flyers in the first round.  Which was nice, but there was no way they would advance.  Sure enough, with a chance to win on the road, they went down 3-0 against the Flyers, and then Maxime f’ing Talbot decided to get his ass kicked by Carcillo in a fight.  Totally pointless.  5 goals later, on to the second round.

Ovechkin and Crosby went toe to toe.  The Pens went down 2-0, and looked hopeless.  Save of the year against Crosby in game one, no less.  ESPN talked about the Caps as the future of the league.  Then a bounce shot of the ass in OT and they were back in it.  Up 3-2 at home with a chance to win, and they blow it.  Game 7 on the road.  No shot.  And Fluery stones Ovechkin and the Pens crush the Caps.

They face a Hurricanes team that overcame two ‘better’ teams to make it to the conference finals and are spent.  The Pens go ga-ga and sweep into the finals.

At this point, I’m telling people that I’m ‘cautiously optimistic’ in order to watch the Red Wings jump to a 2-0 lead in the series.  Malkin loses his mind at the end of Game Two and it seems hopeless.  Then the Pens win two at home, never easy.  Hope raises its head.

And then the Pens get just crushed in Game 5.  To say it wasn’t close is an understatement.  Fleury gets chased for Garon, and you might as well put me in the game.  I’m swearing at friends about my cautious optimism.

And then Jordan Staal steps up when it was needed.  Always (in my mind) the under-achiever, he makes it happen in Game 6.

Going into Game 7, I thought there was little hope they could win.  Last time a road team won was 1971.  Last time a road team won in any of the major sports (the Pirates) was 1979.  They bring out Ali in the 1st period and I’m thinking St. Peter in a Red Wings jersey is next.

And then, Maxime F’ing Talbot.  Two goals, unreal.  Going into the third period, I’m thinking ‘Just hang on.’  Detroit scores with 6 minutes left, and I know, I just *know*, they will tie it to get to OT and then win.  And Kronwall hits the post.  And there’s an empty net and the Pens can’t for the life of them clear the zone.  And when they do, they can’t get the winner.  And they can’t win a faceoff.  And with seconds left, they lose the faceoff, and the shot comes in, and the rebound goes to Lidstrom with a wide-open net, and….Fleury makes the save.  And they won?  Really?  Holy s%^t, we just won the Cup.

You couldn’t script this season and make it seem reasonable or believable.  They shouldn’t have won, but they did.

Obviously, I’ve been watching numerous replays of various parts of the game, but one thing stands out.  Crosby is handed the Cup by the Commish.  He starts to skate around with it, and the shot shows this big burly guy in the lower level in a Wings jersey, flipping him the double bird.  I remember last year, I feel your pain, brother.

Maxime f’ing Talbot.

Stanley Cup Champions 2009 – the Pittsburgh Penguins.


posted @ Sunday, June 14, 2009 1:31 AM | Feedback (1)
pmk – poor man’s kanban – 1 of N – Preamble

There is a lot of existing literature when it comes to Lean/Kanban/Pull/Whatever.  Before getting into my discussion of pmk, although I believe I did this in a previous post, it is important to once again highlight some of the common links to that material.

Lean Software Development

This is most obviously associated with the work of Mary and Tom Poppendieck, since I believe they coined the phrase.

Their work can be found in greatest detail at their homepage.

You can find their books on Amazon by clicking here.

The wikipedia article on it can be found here.


The combination of Scrum and Kanban is associated with the work of Corey Ladas.

The best explanation of what Scrumban is can be found here.

His book on Scrumban can be found here.

Kanban Software Development

A more methodological explanation of this can be found at David Anderson’s site here.

His book can be found here.


So, you’ve given all these links and now you are going to explain why they are wrong and you are right, correct?  Since you are an expert and all that.

Hell no.  I’m obviously not an expert at the level of these people.  What I am hoping to accomplish here is an explanation of some of the core basics of kanban and how it can improve software development.  If and when I have differences of opinion with the true experts (and there are a few), I will say so and try to state those differences of opinion as clearly as I can.  Obviously, if you are really interested in the wide breadth of literature, your best bet is to read it for yourself.

What I am going to try to do is to explain a very simplistic (hence “poor man’s”) version of kanban that doesn’t require any adherence to any particular ‘heavy’ methodology.  This could be considered a deficiency in what I am going to try to explain, and I accept that, but I think there are benefits to taking this route as well.

More to come, starting off with a description of a typical software development environment that doesn’t practice anything like Lean/Kanban/Pull/Whatever, and how poor man’s kanban can improve that environment.

posted @ Sunday, June 07, 2009 11:07 PM | Feedback (0)
pmk – poor man’s kanban – 0 of N

So, I’ve caught the bug.  Okay, a bug.  The Lean/Kanban/Pull/Whatever bug.

Developers like to push things like SOC, IoC, SOLID, TDD, etc. as well as particular tools that (purportedly) help to promote these things.

When you ask developers why these things are important, you get a lot of conflicting answers, most of which devolve to something like “Well, I feel like I’m a better developer because of them.”

Which is nice, but developers (and I am one) seem to like all sorts of things, sometimes because things are ‘cool’ and sometimes because they provide value, and sometimes both.

What I have come to find is that Lean/Kanban/Pull/Whatever (and more on this locution in a minute) can provide both an explanation and a defense of why these things are good.  Or at least can be.

Like all developer-driven things, ‘coolness’ is often times just ‘developer geek shit.’  Not that there is anything necessarily wrong with that, but different developers have different ideas about what is cool.  When should we try out coolness, and when should it be avoided?  How are we to determine this?

Why Lean/Kanban/Pull/Whatever?

Like most everything else, the definitions of Lean and Kanban and Pull are in flux.  There is a lot of debate about what Kanban is, which you can see if you surf the Yahoo Kanban group.  “Lean” when it comes to software development can mean a lot of different things.  Google is your best friend here to see it all, but it derives from Lean Manufacturing, usually tied into how Toyota does things.

But you don’t have to buy into how Toyota manufactures cars to apply Kanban to software development (in fact, I would encourage you not to, more on this later).

Though there is no exact readily agreed upon definition of “poor man’s kanban”, I will define it for reference as the following:

pmk definition

poor man’s kanban:

  • Limits WIP (work in progress)
  • Pulls value
  • Makes it visible
  • Eliminates waste and limits costs

The last item is already controversial (kanban tends to classify everything that doesn’t pull value as being waste, which I think is a mistake), but regardless, what I hope to do is to eludicate these items in explaining why Lean/Kanban/Pull/Whatever is worth pursuing.

posted @ Friday, June 05, 2009 10:02 PM | Feedback (2)
Linq to SQL Not Totally Dead, but it’s not at all well

Jim Wooley has a post that makes what I think is a really good analogy:

Linq to SQL is to Entity Framework as Winforms is to WPF.

That is to say, Microsoft isn’t pulling either Linq to SQL or Winforms from the framework, but isn’t really adding new features to them, just making bug fixes.

Makes sense to me.

posted @ Thursday, June 04, 2009 6:09 PM | Feedback (0)
Linq to SQL Not Totally Dead

Though Microsoft has made it clear that EF is their preferred ORM type thingy of choice, Linq to SQL is still getting updated in .NET 4.0.  List of changes can be found here.

posted @ Tuesday, June 02, 2009 6:20 PM | Feedback (2)