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...

Here's where I suspect things go wrong. I see a combination of two ideas at the core of a lot of corporate dysfunction. I can want things faster than you can build them. I believe that you can always do more if you really try. The former is obviously true. Wanting is cheap, instantaneous, and unencumbered. I want a car with a 500K mile all-inclusive warranty, Maserati looks and performance, moped operating costs, and a Hot Wheels sticker price. And I want it to drive itself. I am betting that the average reader had at least three improvements they would make to my wish list. None of us expect to see such a thing, of course. The engineering and design costs and material costs make this impossible. Wanting is cheap, but invention and production are expensive. There are material costs, costs of design, costs of errors and rework, costs of research, time and materials. There are human beings who do design, and they like to be paid. It takes them longer to work out the requir...

It seems obvious that you can go faster if you take longer strides and cut corners. In software, this is very much false. Be advised.

GeoCaching is a quirky, slightly geeky, fun treasure hunting game made possible by the ubiquity of GPS devices on the market. Essentially, person A will hide some object somewhere on the face of the earth, then publish the location as GPS coordinates. Person B will find their way to the given coordinates, take the object left by A, and replace it with another little gift/trophy for person C who might come along later. The locations may be at the bottom of a lake, top of a mountain, inside a cave, in a hollow tree, underground, in the hulk of an abandoned vehicle, etc. The game, therefore is partly in hiding the items in fun places, and partly in finding the items. Geocaching in "meatspace" is fine, and probably a lot of fun (I've not had the pleasure personally). Geocaching in software is wrong. I have found classes which contain something like this: public class Location{ private Item XXX; public Item Xxx { get { return XXX; } ...

Noob asks: "How much is a story point?" Master looks on card wall, says: "We do 16 each week." Noob asks: "But how much work is it?" Master says: "One sixteenth of a week right now." Noob is enlightened.

Today I found code that looked like this: public IList SetSomeAttribute(); Notice anything funny? A setter method that takes no parameters, so there's nothing to set, and returns a list of some sort. Hmmm... Did the author mean "GetSomeAttribute" instead? It turns out that the code cleared an instance array, then rebuilt it from data present in an indirectly-held instance of another class, and finally returned the newly reconstructed list. So, it seems that the method was caching some other class' data, and returning the local version. One could wonder whether that makes any sense or not, but first one has to grapple with the bizarre method interface. We only had a little time. We fixed the query/command separation right away and renamed the method, but I think there's likely something wasteful and wrong going on in there. Maybe Monday we can sort it out.

Yikes. My new partner and I had a task which involved a new feature. The complication is that the current version of the feature was implemented almost entirely in the initialization method of a web page code-behind class. Yeah. The method that we wanted to test in Fitnesse was almost entirely written into the GUI, and worked entirely in terms of the query it was building to populate the screen. This was not welcome news, because the Fitnesse test couldn't make use of the UI Screen's code. Sadness is that this situation isn't all that uncommon. In my last company, there was code that implemented the same feature two different places: once in the web UI and again in the report generator. Of course, changes to the one would not affect the other. The code had two different maintenance points, and each was written in an idiosyncratic way to thread the calculations into the screen or report. A customer was simply flabbergasted that the developers had written the same fun...

You know you're in trouble in hardly more than a glance. All the methods are long and busy, and do their work data members of other classes... other classes without any behavior. Methods are placed in ersatz global functions. Why? Because that's where they're closest to the runtime. Perhaps in module initialization, perhaps one function call away from the "static main." The solution for the code is well known. Extract method, move method, pull up method, red/green/refactor. The real problem here is that we don't know enough about prevention. Why do we keep getting saddled with busy methods running roughshod all over beany classes? Is it laziness, poor education, a lack of good examples, a confused sense of practicality? The human problem is interesting enough that I need insight from a wide range of agilists.

I'm back (with my partner) working on the same stinky stuff I blogged about earlier . That code all made it back to the main codeline where we can refactor it but we had to lose a lot of our refactoring in order to get it back in. It was a lesson learned. We had to abandon some changes because we let our code diverge too far from trunk. Now we know about code perturbation . Then there were bugs in the mudball function, and bugs are always bad news. These were mostly of the "implicit" variety. Code that falls through the "if" traps in a certain way, combined with some default settings in some of the variable(s) at the start of the method, in between the interwoven concerns and feature-envy ... I really want to get in there and get it under control (which is to say, wrapped in a fuzzy blanket of unit tests). Sadly the blanket does not start out soft and fuzzy. It's a blanket of glass shards and barbed wire. In this case, the test doubles (testable classes...