Posts
832
Comments
691
Trackbacks
1
December 2008 Blog Posts
When Marketers Aren’t Paying Enough Attention

I got a marketing email from the PGA Tour today, and it had this subject header:

“Ah, For More Penetrating Trajectory”

I don’t know if I should be happy or sad the spam filters didn’t pick it up.

posted @ Wednesday, December 31, 2008 4:00 PM | Feedback (0)
There’s a Lesson about Software Development in there or something

Read this comment in code today:

“the optimizer was breaking the code up inefficiently”

posted @ Wednesday, December 31, 2008 3:44 PM | Feedback (1)
Some Lean Software Development Links

So, I am working through my backlog of webcasts (Ha, ha, I made a funny…see there’s this notion of a backlog and….oh never mind), which includes the content produced from the Kaizen/Echo Chamber Conf event this past November in Austin (at least for the non-cowards who didn’t password protect theirs), and one of the sets I watched today was a high-level overview of Lean/Kanban led by David Laribee.

Depending on how versed the viewer is already, the value you can derive (Ha, ha, I made a fu…never mind) from the videos (3 of them) of the session may vary, but I found the visual presentation of the concepts to be, well, valuable in getting a high-level overview.

Now, there is a *hell* of a lot of jargon involved (“We produced a Kaizen event….Oh, I’m so sorry, is there a prescription for that?”), and if that’s the sort of thing that will bother you, then you may be bothered by some of it (depending in part on how you feel about white boys using Japanese terms).  Since part of my dissertation involved an analysis of parts of Heidegger’s Being and Time, arguably the most jargon-heavy (and some would say, incoherent) philosophical works of all time, that doesn’t necessarily bother me so much.  Learning the terminology allows one to converse more efficiently.  Plus, Dave has a way of defining ‘way tasty’ (I think that is what it was) that is funny yet insightful.

It’s worth a view, in my opinion.  A couple of other links came up in the videos, so I’ll list them here:

Kanban Yahoo Group: remember folks, if you want to learn without looking foolish, there’s nothing wrong with lurking an active discussion group.

Lean Software Engineering: a site with a lot of essays involving, well, lean software engineering.

Rolling Wave Project Planning: a white paper about a different way of project planning.

And of course, Google is your friend.  And more obviously, if you want to learn more about Lean, find someone who has practiced it.

posted @ Monday, December 29, 2008 5:22 PM | Feedback (0)
DDD-Lite: It takes longer to develop code using TDD, but so what?

One of the (potential) criticisms of using TDD is that it takes longer to develop code when practicing it.  The topic is too large to really address in depth in a blog post, but I want to touch on it here, because I think, in general, it is true, but not necessarily a compelling criticism.

On the face of it, it is obviously true in a certain respect.  Writing tests to test your code requires, obviously, writing more code.  Thus, since it takes longer to write more code than it takes to write less code, using TDD takes longer.

Now, as just about anyone who has written TDD attests, developing using TDD requires a change in mindset, a change in basic practice.  I think this is true (though trying to quantify it is a fruitless exercise).  Think about learning any substantial OOP pattern.  When you start to learn and apply the pattern, it takes time because learning and applying it isn’t instantaneous.  Once you understand the pattern, its application becomes natural, but before that, it requires some conscious effort that slows you down. 

The same can obviously be said about TDD.  When you ‘just’ write code, you write it however you write it.  Forcing yourself to write tests before writing the code under test requires conscious effort if you aren’t used to it (I think some people will pick up on it almost immediately, for others, it takes longer…I’m in the middle somewhere).  As it becomes more natural, you can apply the practice more effortlessly.

But you are still writing more code.  So, it takes longer.  Moreover, once you commit to writing tests, you commit to refactoring the tests as you refactor your code.  Personally, this is probably one of the biggest time costs associated with TDD.  A common ‘pattern’ that I’ve found is that you decide to refactor code to reduce repetition, and as a consequence have to refactor all of the related test code to account for this. 

But (he says again), if the benefits of doing so outweigh the time cost, then it isn’t really a criticism of TDD.

Advocates of TDD have talked about the benefits much more eloquently than I, but let me grossly paraphrase some of them potential benefits as I see them.

A very obvious potential benefit is the reduction of time spent in debug mode.  Especially when you are developing non-UI related code (which, MVC notwithstanding, is intrinsically harder to test), using TDD to write domain-specific logic (which is something I’m spending a lot of time on right now, so I’m focusing on that) that allows you to write code that meets its specifications (I know that ‘specification’ is a loaded term, but let’s go with it) much more quickly, without having to jump into the debugger to determine that your code does just that.  I will admit that I still, on occasion, will jump into the debugger, in part because I know that I am not currently totally confident in my test-code writing ability, but that is a ‘criticism’ of me, not TDD. 

People like Derik like to talk about the ‘safety net’ of testing (the term ‘safety net’ comes from another Alt.NET’r from the Chicago group but I think it matches what Derik has expressed in the past) and I know what that means.  I recently worked on a project where (for various reasons) I could write tests for half of it, but not the other half (it would be comical to explain why, but would take too much time and probably violate an NDA or something).  Because of the tests that I had for the first part, I was much more confident (not totally, see above about my self-assessment at test-writing) that I would not get bugs from the QA department about that part, as opposed to the part where manual testing was required.  Both ‘parts’ were non-UI related, but only the testable part could be, well, tested, independently from other people.

That right there indicates a way in which the benefits of TDD can become more apparent.  TDD allows you to write code that doesn’t require other people for immediate verification (you always need later verification, but that is true of any code in just about any situation). 

The biggest potential benefit is that you can prevent the bugs that the QA department will surface in the first place.  You could argue that this is, in fact, the real point of TDD.

I am ambivalent about this.  Without something like BDD-style specifications (I don’t like a single implementation of BDD that I’ve seen, but the core idea behind it seems solid), I think this is a hit-or-miss proposition.

In any event, I don’t think the ‘using TDD requires more code’ is really much of a criticism, by itself.  As a big fan of using MVP with WebForms, I know that using the MVP pattern requires more code, and as I’m writing it, I’m often annoyed about it, but I think the benefits of MVP outweighs the cost.  Similarly, the same should hold with TDD (or some form of it, anyway).

posted @ Wednesday, December 24, 2008 6:39 PM | Feedback (1)
OCMA: The New Pornographers – Adventures in Solitude

Reminder, ‘OCMA’ stands for ‘Obsessive Compulsive Music Awards.’

Do you remember the old late night TV ads for music collections by ‘K-Tel Records’?  For whatever reason, I remember one being ‘The Best of Bread.’  Really?  They had enough songs to have such a collection?

Anyway, I imagine in the future that someone will have a music collection entitled ‘Best Songs from the WB Network’ or something.

This song would make that collection.  But I like it anyway.

As I’ve often said, I don’t look to music lyrics for meaning.  If I want meaning, I’ll try Shakespeare or the Bible.  Regardless, this song does a remarkable job of being incoherent.  Did I mention I like it anyway?

From the title, the song is obviously about solitude.  Not that I know anything about that, but I can relate.  It is also about reconnecting:

“We thought we lost you
We thought we lost you
We thought we lost you
Welcome back “

There’s also an understanding that solitude has its reasons (did I just type that?  What blahblah):

“I know you want to
Run far away from one more
And that it's comin' at a bad time
Some cold place
Heartless ways
For all we know


I know you need to
Breathe through
Come back
Come too
But it's comin' at a bad time
Tangled day
For all we know “

I couldn’t possibly explain coherently what those lyrics mean.

But, the song is really f%%king pretty, which is why it won an OCMA.

posted @ Tuesday, December 16, 2008 7:34 PM | Feedback (0)
DDD-Lite: Unit-testing Constructors

update: updated the first test so that the constructor is doing something, since that was kind of the point.

When I was first learning about TDD, the guy I knew who was actually practicing it unit tested his object constructors.  Obviously, it was a different domain, but I vaguely recall that it looked something like this:

[TestMethod]
        public void can_create_an_item()
        {
            Item i = new Item(“Name”);
            i.ShouldNotBeNull();
            i.Name.ShouldEqual("Name");
    }

Being the helpful kind of guy that I am, I made fun of him for it.  This is where I asked him “do you unit test that Int increments properly?”  He’s normally a well-rounded, easy-going, good-natured kind of guy.  He didn’t think it was funny.

Fast forward a couple of months.  I was putting together a small domain model for some trivial app, and so, of course, was creating classes through the time-honored tradition of copy and paste.  God being Just, I forgot to fix up a copy and paste procedure and so one of my object construction had a bug in it.  Naturally (especially since I gave him a hard time about it, I had to), I told him about it and his response was something like “In your face for the mother-f%&king win!”

Anyway, as I put together this new system, I come back to the question of whether to unit-test object constructors.  I still feel, well, a bit dirty, or stupid, doing it.  Am I really going to test whether I can assign a string to a string property?  Really?  TDD of the strict variety says I have to.  Well, okay.  For now.

digression: besides the fact that it just feels silly, what I don’t like about testing object constructors is that as I go down the road and add new properties and such, I will have to remember to add them to the constructor tests.  This is an obvious area for potential screw-ups.  This is something that code generation can help with (yes, I know, I know, code generation is bad/flawed/whatever.  You’re wrong, so bite me), as repetitive code should ideally never be hand-written.  Refactor project for later.   Eventually, there will be Validation tied into the whole thing, so that a constructor test will fail if a required property is added, but I haven’t decided how to do the validation piece yet, so I’m YAGNI-ing it for now.

But, there is another area where it makes a little more sense.  I’m ripping off ObjectBuilder type syntax to add a little bit of fluency.  So, something like this:

[TestMethod]
        public void can_create_an_item_using_fluent_syntax()
        {
            Item i = new Item().WithName("Name");
            i.Name.ShouldEqual("Name");

        }

I feel better about this sort of test, because I am testing a ‘fluent’ (is it fluent?  is it a good idea?  I’ve decided to use it, so that is good enough for me right now) syntax on top of the normal object constructor stuff.

In the long run, I am pretty certain that I will decide not to manually write normal object constructor tests.  But, I am going to stick with it for now.  The immediate downside is that I need to write 2 tests, one with normal syntax, one with ‘fluent’ syntax.  For now, I’ll eat the three minutes it takes to do that.

posted @ Tuesday, December 16, 2008 7:18 PM | Feedback (3)
DDD-Lite: TDD, (B)DUF, and Testing the Framework

I’m going to be randomly posting about things that come up as I build out what I am calling a DDD-Lite application, as much so I can record decisions I made along the way for anything else, so that if I decide to change something down the road, I have at least so record of why I did things the way I did in the first place.

To group them together, I’m tagging them so that they can be viewed as a group here.

TDD stuff

When I was first learning about TDD (which was relatively recently, some time in 2006, I think), I knew a guy that was actually practicing it, and I used to ask him why he didn’t have test methods like this (I’m using syntax and that whole godawful underscore naming method stuff):

[TestMethod]
        public void when_incrementing_an_integer_it_increments_properly()
        {
            int integerUnderTest = Int32.MinValue;
            integerUnderTest.ShouldEqual(Int32.MinValue);
            for (int i = Int32.MinValue + 1; i <= Int32.MaxValue; i++)
            {
                integerUnderTest++;
                integerUnderTest.ShouldEqual(i);
            }

        }

Surely (don’t call me ‘Shirley’), surely, your application uses integers, right?  If you want 100% code coverage, you need to know this works, correct?

Now, no one that I know of thinks that TDD requires you to have tests like this (in case you are wondering, on a Quad Core Q6700 box with 4 GB of memory, the unit test timed out after 30 minutes).  But, I mention this because I decided that, to the best of my ability, I was going to practice TDD unless and until I couldn’t anymore for a legitimate reason.

disclaimer: some might wonder, given my critical stance (some might say ‘open hostility’) towards TDD, whether I could possibly follow the practice.  Though I guess the reference will be lost on almost everyone, this is nothing compared to my feelings about Quine’s behavioristic stance concerning the philosophy of language.  I found just about every aspect of his philosophical work to be obviously and fatally flawed, but though no one openly advocated the specifics of his behaviorism anymore, the influence of his writings and theories (his indeterminacy of translation thesis in particular) was such that the only way I could properly reject them was to do everything I could to imagine in the best possible light why someone would believe his position, and from that standpoint, point out the weaknesses.

I bring this up for the hell of it, but also because of Paul Cowan’s recent post on DDD, and the response it generated.  A lot of people responded that Cowan didn’t really understand DDD.  I will accept that for the sake of argument, but point out that it is also largely irrelevant.  Cowan meant his post to be semi-serious (which some people missed), but there was a central point to his post that I think is absolutely correct.  It doesn’t matter whether Cowan ‘really’ understood DDD if his criticism was sound, but that isn’t something most people can handle.  Few people can handle the philosophical rigor required to properly analyze theories and positions without taking the personality or persona of the person stating the theory or position, and that is unfortunate, but regardless, I want to be able to describe, analyze and practice TDD as best as I can.  Even if ultimately I want to offer a replacement.

Immediately, then, when deciding to practice TDD, you have to decide whether you want to shoot for 100% code coverage, but the ‘int test’ makes it clear that the notion of ‘100% code coverage’ isn’t clear.  And so when I decided to do TDD on this DDD-lite thing, I had an obvious problem.

As smarter people have said, TDD tells you what to do, but it doesn’t tell you where to do it.  BDD is supposed to help out here (work with your stakeholders to find out what you need, blah blah blah, yada yada yada).  However, this doesn’t help me here for (at least) two reasons:

1) Though I am not the only one, I am the main stakeholder as well as being the main developer/architect/blahblahblah.

2) I hate BDD more than I do TDD, and I feel the need to grok first things first, so to speak.

One of the other things that makes it really hard for me to do TDD has to do with design.

Design stuff

When done properly, I gather that TDD done properly offers (at least) the following benefits:

1) YAGNI done right: you only code what you need to code, when it needs to be coded.  Instead of the possibly random and too-far-forward thinking that can come from upfront design (“we need to log what this file service does, so let’s design a logging service that can log anything we can think of upfront before we actually need it”), you design and code for what you need *now*.

2) Cleaner API: our tests help us to define the API our calling code will actually prefer, in terms of what we need *now*.

An immediate problem arises.  What if you are building a greenfield application that is supposed to be a refinement of all the practices you’ve done previously within a given domain?  I already know a lot of features and functionality that the domain is supposed to address, but TDD seems to involve what might be called ‘purposeful lobotimization.’  I already know a *lot* about what the domain model should look like, but TDD stresses that I shouldn’t build the domain model without supporting tests.  So, I find myself defining a lot of tests, not in terms of developing a cleaner API, for instance, since I already know what the API should look like, but because that is what TDD says I should do.  Personally, I find this *very* hard to do.  Writing the tests first slows down the development process. 

More generally, if you are designing an application, you should have some previous knowledge of the domain that you are working in (unless you are a pure contractor on a project).  Because you already know this, you already have a general inkling of ways in which your domain is going to be used, even if you don’t have immediate calling code *right now* that defines that usage.  But TDD says not to write that code yet.

Framework stuff

Why is it that TDD doesn’t require you to test Int?  Int is part of the .NET framework.  Unless you have a specific bug related to the .NET framework, you shouldn’t have to test framework code.  It should be assumed to work.

When writing your own code, I think this rule should apply (maybe).  If you are creating framework-type code, maybe you test it at some basic level, but otherwise, you shouldn’t have to.

Currently, I am violating this rule, let me explain why.

Let us assume the domain is related to an inventory management system.  Within this system, you know you need to handle an item/SKU.  An item could have many properties and behaviours, but let’s assume a bare minimum, that any item has a name and has a set of attributes.  For instance, a t-shirt will have a color and a size.  So, from a domain modelling perspective, we know we need to create an Item classs that has a name property and an Attribute collection.

On the surface, the Attribute collection has similar characteristics to an Int.  If we add an Attribute to the collection, do we really need to assert on the count of that collection?  I would hope not. 

But, in this domain, there is some logic involved.  Suppose you have an item that has a Size attribute already defined in its Attribute collection.  If you try to add another Size attribute, what should happen?  I know that what should happen is that the Size attribute should be replaced, not added.  TDD rightly tells me here that I should ensure this behavior exists.  If I add a Size attribute to the collection where that attribute already exists, the count should stay the same and the value should be the new value added.

Summation

TDD, strictly applied, does seem to slow down the development process.  The cost of this slowdown needs to be held up against the benefit of applying it.  As of now, it seems to be a good thing to do. 

posted @ Monday, December 15, 2008 8:49 PM | Feedback (0)
This seems to be a bit much

I can’t say that I agree with this totally, but I did have a couple of LOL moments, such as with the ‘and probably eats babies’ line.

Enjoy.

“Cram your test driven development up your ass.…”

posted @ Sunday, December 14, 2008 2:17 PM | Feedback (6)
OCMA: Loquat – Swingset Chain

Another in my random series’ of musical posts, OCMA stands for ‘Obsessive Compulsive Music Awards’ wherein I identify songs that, once first heard, I tend to listen to a lot in a short period of time.  And I mean a lot.  Like double-digits a day.  Or, an hour, if I’m really locked into it.

Since much/most of what I listen to still tends to be what is called ‘Progressive Rock’ (whatever that means), many OCMAs would go there, but I want to start off with a song (or two, depending on when I get to it) that doesn’t fit that category.  Instead, it is a song that fits into the ‘one-hit wonder’ category, although the song was never a hit really, just one song from a group whose output otherwise, well, kinda sucks.

The band is Loquat.  Having just looked it up, a loquat is a type of fruit tree.  I suppose that’s as good a source for a band name as anything.

Anyway, the song is called ‘Swingset Chain’ and is a song about the absence of a friendship (whether temporary or permanent isn’t clear), the recollection of memories of someone absent.  It’s reminiscent of The Sundays and their hit “Here’s Where the Story Ends”.  A female singer with a pretty voice singing over a ‘lush’ arrangement (whatever the hell that means).

Since the song is about absence, the lyrics are, naturally, poignant:

“There's a playground that we used to run on
The penny-drop that broke her arm
The monkey bars that you fell from
The swingset chain that stuck with my tongue
It's thirty below and we're far gone
If you plant yourself here I wouldn't miss you for long
But then comes the day when you leave town
I'm back to the way I was when you weren't around”

and later

“You're a dandelion seed
That flies through the air
And lands randomly
Then disappears”

It ain’t Shakespeare, but as I’ve mentioned previously, I don’t really expect Shakespeare in my rock lyrics.  But, it does evocatively and hypnotically capture a mood (the cynic in me says it needs a guitar solo, but not everything needs a guitar solo….most everything, but not everything).

posted @ Monday, December 08, 2008 10:10 PM | Feedback (0)
Why the Penguins won’t win the Stanley Cup

I’m watching the Penguins-Sabres game on Versus HD.  Going into the 3rd period, it is tied 3-3.  I have no idea who will win the game (if the Pens were down by 2, I’d say they win, if they were up by 2, I’d say they lose, since it is tied, it’s a tossup), but watching the game reminds me not only why they are one of the most entertaining teams to watch (are they winning?  Don’t worry, they’ll give it back.  Are they down by a couple with four minutes left?  Don’t blink, they are now up by one), but why they won’t win the Stanley Cup.

I was surprised they didn’t get swept by the Red Wings in the finals last year.  They really had no business winning a single game, much less two (but we’ll always have that 3 OT thriller), because of a couple of fundamental flaws, which you wouldn’t necessarily think are flaws on the surface.

Anyway, so in this game, every single goal the Sabres have scored so far has been due to a giveaway by the Pens when they had full control of the puck.  That obviously isn’t a good thing, but that’s not the real problem.

The real problem comes from how the Pens scored their 3 goals.  All three efforts were beautiful tic-tac-toe type plays, brilliant pass (or passes) leading to a near empty net for the goal.  Exciting to watch, and the skill level is evident (Malkin with the first two assists, Crosby on the third).

During the telecast, the announcers mentioned that the Pens are almost always out-scored, that they are second to last in the conference in shots on goal, and found it surprising.  No, it isn’t.  Because the team has Malkin and Crosby, and because they make such brilliant plays, the team expects all goals to be like that, and so they don’t shoot the damn puck enough.  Why shoot it on net, when you can try to pass it through three people in a highlight reel goal?

The scary thing, of course, is that Crosby in particular can do this.  He can pass it so that it flies over the first defenseman’s stick, then under the second’s, right onto a teammate’s stick who taps it into the net.  Recently, Crosby has tried a new tactic and the scary thing is it works.  He shoots a slapshot, but not at the goalie.  No, that would be easy.  Instead, he shoots it *at a teammate’s stick* so that it banks in off of it.  He’s done it off of Sykora and Staal the last week.  And it isn’t a fluke, he’s doing it on purpose.  Their sticks break, but it’s damn impressive.

We’ve seen this before.  The early 90s championship teams had Lemieux and Jagr (just as importantly, Ron Francis).  They won two Cups, and should have won more.  The team going for the three-peat is widely regarded as the most talented.  But they lost in the playoffs in 7 games to a vastly inferior Islanders team because they kept trying to make the prettiest goal possible, while the Isles just shot the damn thing.

I suppose this year has shown a progression of sorts.  Crosby and Malkin have both scored amazing goals when they try to go one against four or five, and used to insist on trying it once a game.  They tried it continually in the finals against the Red Wings, an older and more experienced team that just shrugged the young punks aside.  The first part of this year, Crosby and Malkin were at it again, trying for the one on four highlight reel goal at least once a game.  Now, at least they are trying to bring their teammates into the action.

But please, guys, sometimes it pays to just shoot the damn thing.  Why do you think Max Talbot is on the team?

Update: The Pens lost 4-3.

Another update: from the ESPN recap -

"The power play is not good," (Coach) Therrien said. "We are trying to be too cute."

The Penguins enjoyed 3:35 of two-man advantage time during the game over three stretches, including a full two minutes midway through the second that could have given them a 4-2 lead.

"They didn't put too many pucks on the net; they tried to be a little too cute and go for an empty net," Sabres defenseman Jaroslav Spacek. "They had a couple chances but we did a good job with some big kills, especially the second five-on-three."

posted @ Monday, December 08, 2008 8:27 PM | Feedback (0)
No Best Practices

This isn’t a new post, but it makes a lot of points that are relevant today.  This week, I particularly like this one:

“Go ahead and follow your favorite practices. Just don’t preach that the rest of us must follow them, too. Keep your process standards to yourself. If you want to make a suggestion, make one that takes context into account.”

posted @ Sunday, December 07, 2008 7:52 PM | Feedback (1)
Note to the people using or supporting the Food Bar

To those people who set up the Food Bar, you really need to think about the placement of the food as it relates to how normal people will function.  So, for instance, when you set up a taco bar that moves from right to left, putting the taco shells and tortillas at the left end after the meat and the rice *completely* screws up the flow of people, since they then need to get the shells and swim upstream back against the line, and this just slows everyone down.

To those people using the Food Bar:

- if the flow of the food bar is a little screwed up, this does not mean you are then free, willy-nilly, to move up and down it as you decide what you want.  There are other people in the line.

- it is certainly difficult at times to decide which of the wonderful selections you have to choose from that you wish to eat, especially with the hot food.  I mean, the rotisserie chicken has such a nice crust and juicy interior, the veal parmesan has a delicious sauce and the enchiladas, especially the ones with the white sauce, are absolutely scrumptious, but MAKE UP YOUR GODDAMN MIND ALREADY. 

- if it takes you more than 90 seconds to figure out how to use the salad bar, bring a sandwich from home.

Thank you.

posted @ Thursday, December 04, 2008 7:13 PM | Feedback (0)