Agile Otter Blog

After a fresh checkout, a number of tests started failing on my laptop. This is new (within the past week or so). The problem is actually fairly tiny, but is a good lesson on testing in the presence of environmental assumptions. Apparently there are customizations which we can apply to our computer's "en-US" mapping, like choosing 24-hour clocks or military dates. Of course, I had done so when I first got my computer because I like military style date/time strings. It never mattered at all until this morning. So look at this line: CultureInfo culture = new CultureInfo("en-US") When we call it, we don't get the unmodified stock version of en-US (what ever the heck that might be) but our customized one. This is generally good when we're working on our own laptop, because we get the version we've configured. In unit tests, though, it's not so good. The tester's machine was not set up quite like my machine, and this caused the failures. As...

I'm planning four blogs this month to be part of a suite of "tricks". This little blog will act as the placeholder for links to all four of them. Agile is a management trick to exert more control over development. Agile is a customer trick to make development do what they want. Agile is a ploy by QA to take control of the development process. Agile is a programmer trick to manage their workload. Historically, none is strictly true. But I think they're all true. I will welcome your feedback, as always.

The point of good naming is not to make the names long but to make them clear and obvious.  A coworker showed me some code where variable namess were descriptive, but rather similar to each other in shape and containing some of the same words.  He then showed me the same code where the variable names were replaced with X, Y, and Z to illustrate that (even in this case) shorter names were superior. He was right.  When I'm looking at code, I need to see its structure. When long identifiers obscure the structure, will struggle.  I also need to see all the ways a given variable is used in the function. If I can barely tell the difference between variable names (ie I have to READ them all to tell them apart) then it's more work.  Is a short, distinctive, nonsensical name better than a long hard-to-distinguish name? Can that be true? In the context of a passage of code (not just an isolated name) it certainly can be true.  A short, distinct, and clear name is eve...

This is the place for you to regale me with stories of backslides . I am interested in how it happened as well as your guesses as to why. Is agile too counterintuitive? Does the method underdeliver? Are managers too addicted to practices made impossible in agile? Was it too hard? I'm hoping to learn and adjust my perceptions. You can help.

A recent tweet captured a sound bite from my friend and mentor Robert Martin. I don't believe it is misquoted: "A 40 hr week is not the choice of a professional" @unclebobmartin As a friend of UncleBob, I know what he means, but I fear that this quote is too easily hijacked. I tweet the same: Be careful with your sound bites. It is their misinterpretation that will be implemented. As a counter-soundbite, I offered this to the ether, in hopes of seeing some refinement of the idea in twitterspace, and especially hoping to counter a wave of 70-hour-week taskmasters. A good point, yet how much should we take from faith, family, friends, and such life-giving pursuits? ... discussed? Of course, Dave answers back, channeling UncleBob. This answer is still prone to abuse, but is generally better and safer It is: ... that self improvement & learning is your responsibility, not your client/employer's. This is clearly true. Taken correctly, it tells us that we should self-e...

It is backlog management. Everyone is talking about "value" and "maximizing the work not done" and "minimal marketable features" and "prioritizing." I've been thinking for a while that the problem in a lot of "agile organizations" is that the "agile" ended in the programmers' bullpen. Getting agility pushed into management and Customer hands is often like pushing a rope. A recent blog ( "Platitudes of Doom" ) covered part of my concern. Instead of enjoying yesterday, I spent a lot of it pondering the reasons I've seen so much dysfunction in this area. Of course, it is partly Taylorism (hello Darrin) since a lot of people filling the Customer role aren't paid on the basis of making the product better, but on the basis of making particular external customers happy. Often this places the marketing/product people in competition with each other for development time. If A gets his changes thro...

It's not just a good idea for you, it's a better idea for me. I admit to being a little run down from my last nine days of activity (college for son, travel, etc) and also have other stresses, but I was feeling the negative yesterday. I don't like that feeling. I could have been enjoying all the agile peeps at Agile 2009, but instead was fretting about vendors selling agile-in-a-box and various dysfunctions in the Customer space (see previous blog). I admit that dysfunctions fascinate me, and I can spend too much time with the magnifying glass over my eye. CS Lewis said that he was not a pleasant man when writing "The Screwtape Letters" because he was in the head of his antihero demons for too much of the time. I think I can also spend too much time fretting about dysfunction. Odd, that. Here I am surrounded by the people who do agile well, and fretting about those who do not. I stayed up with Brandon, Joe, Bonnie, &all last night too late, but this morni...