Exploration Through Example

I was using FlexMock to test code using Cocoa NSNotifications. I discovered an odd thing, which might be useful to someone doing a Google search some day.

My setup code originally looked like this:

  def setup
    @observed = NSObject.alloc.init
    @watcher = flexmock(NSObject.alloc.init)
  end

The notification connection was set up like this:

    center = NSNotificationCenter.defaultCenter
    center.addObserver_selector_name_object(@watcher,
                 :posted, "name", @observed)

That didn’t work. FlexMock recorded no calls to posted. I discovered that it worked if FlexMock were given a descendent of NSObject instead of an NSObject itself:

  def setup
    @observed = NSObject.alloc.init
    @watcher = flexmock(SomeRandomWatcher.alloc.init)
  end

SomeRandomWatcher is a pretty simple class…

# Use this class when creating a mock that’s to receive a notification.
# I don’t know why you can’t use NSObject, but you can’t — the notification
# will not be received.
class SomeRandomWatcher < OSX::NSObject
end

You can find the rest of the code here: mock-example-notifications.rb. I have an idiosyncratic style for writing mocking tests. Explanation of the syntax I use is here.

You can run the example if, at some point in the past, you’ve installed these gems:

$ sudo gem install Shoulda
$ sudo gem install flexmock

I’ve been beating my head against the technical debt metaphor a bit these days. Here’s one thing that oozed out.

Preface: I’m assuming there are two kinds of debt. One is frivolous debt; the other is debt-as-investment. When debt is an investment, you have a reasonable expectation that a bulk sum of money now will allow you to start something that will, at some future time, produce excess cash greater than the cumulative interest on the debt. For example, you borrow money to buy a car because it lets you choose from more—and more kinds of—jobs. More opportunity means greater lifetime earnings than if you rode the bus while saving for a car.

Business pressure to add technical debt to a code base usually is couched in terms of debt-as-investment: “If we miss that market window, we’re out of business, so it won’t matter how scalable the code is.” (Whether the expectations are reasonable, and whether the same parties pay for the debt as get the increased returns, I leave for another day.)

Frivolous debt is different. For example, John McCain and his wife recently had USD10,000-15,000 in credit card debt at 25.99% interest. There’s no reason for them to pay that stiff an interest rate, but what the hell: she made more than USD6,000,000 in 2006, so why sweat interest charges? More commonly, though, frivolous debt does matter, and it comes from ignorance. In code, for example, technical debt can accrue because people simply don’t know guidelines like “Tell, don’t ask” or “Don’t repeat yourself“.

In what follows, “debt” means “investment debt.”

The analogy to a growing GDP

We imagine that debt-free code is without history. Suppose that, during development, classes Foo and Bar split into Foo, Bar, and Baz, and some of Foo’s methods were merged into Bar. If you were coming on the project, I should be able to explain why Foo, Bar, and Baz make sense without referring to their history.

History only comes up where there’s technical debt. It makes you say things like “there’s duplication between Foo and Bar because we didn’t realize fact X until new story Y and we haven’t time to finish merging their behavior.”

I have a sense that telling that story isn’t just a way of making excuses: it’s actually important for being able to work with the code in the presence of debt.

But, because we have this history-free ideal, we don’t pay attention to that. Maybe embedding history in the code (somehow) is a way of increasing the debt load the team is capable of supporting in perpetuity.

So, where I had been thinking about how to reduce debt, now I’m thinking about how to make it matter less. Like there are two ways to solve the problem of an insupportable national debt: you can pay it down or you can grow the economy.

I’ve come to think of Open Space workshops, as used in the Agile community, as having three purposes.

1. They give people a sense of belonging — “I’ve finally met people who care about what I care about! / are grappling with the problems I’m having!” This is by far, to my mind, the most noticeable result.

2. They provide individuals who have problems with help. The effect can be anything from a shallow “I could try this…” to a real Aha! moment.

3. On rarer occasions, people who have decided to devote themselves to a broader topic can get, over the course of the workshop, a solid sense of what the most important issues are. That issue survey informs their later efforts, though I don’t think it itself provides a solution or a plan toward a solution. (The survey of Agile testing issues that Bret Pettichord, a few others, and I got at the 2004 XP/AU Open Space was invaluable.)

I think Open Space in our community is not a tool for solving a big problem by gathering together a group of people devoted to it and having them tackle, in small & fluctuating groups, those parts or aspects of it where they can best apply their talents. I believe that was Open Space’s original purpose.

My disenchantment with Open Space is mostly a result of my own poor expectations and personality traits. I am by nature a “let’s solve some big problem” kind of person in any group setting, so I’m attracted to that original purpose of Open Space Technology and disappointed when it doesn’t emerge. I’m also not a person who’s moved by a sense of belonging (except in an abstract, “community of ideas” way).

For large-scale problem-solving and the pushing of abstract ideas, I prefer the LAWST format. Because the sessions are focused on asking questions of a particular person who thinks she has an idea to share, you can get a longer and more in-depth understanding of a topic. But because the schedule is even less planned than in Open Space, there’s more opportunity for the different sessions to cohere into a sense that the workshop was about some-thing and that conclusions were reached about that thing.

How that works:

1. In one of the presentations, someone says something that strikes a chord.
2. The collective intelligence amplifies that chord through questioning.
3. People who have more to say about that chord put themselves on the schedule.
4. People who don’t take themselves off, or desultory question shortens their time.

LAWST is a pretty effective blend of structure and not-structure. Good job, Brian and Cem.

OK, I want to try the six degrees of separation thing. I would like to make t-shirts or posters for Retro-futurist micro-scale anarcho-syndicalism. I like the designs from Glennz Tees. In fact, I can imagine a modified version of this Tee being just right for the theme:

I’ve sent email to the mailing address I could find, asking how much custom work would cost, but got no reply. The “about” page says: “I’m Glenn Jones, a graphic designer and illustrator from Auckland, New Zealand.”

I’d like to contact him. If you think you can get a link to this post one step closer to him, I’d appreciate it.

At the very least, this will serve as an advertisement for his designs.

Agile 2008 is calling for volunteers to come help out in exchange for conference registration. Deadline is June 25.

According to Wordle’s processing of this blog’s text from the last six months, here’s what I care about:

I haven’t done the same for last year. If I did, I’m guessing I’d notice the following differences:

• A lot less mention of Fit this year. That’s due to my decision to tone down my emphasis on automated business-facing tests in favor of exploring other ideas.

• Still a lot of emphasis on tests and testing, but less emphasis on testers than last year, and more of an emphasis on programmers. I’m getting a lot more involved in questions of programming and design—playing to my weaknesses, as it were.

• I’m spewing less verbiage about examples this year. Perhaps I’ve made my point.

• Much less about Agile. I’m still not so happy about how it’s being domesticated and exploited, but it’s harder to get excited about it now that I’m no longer in a position to do much about it (not being on the Agile Alliance board any more).

A little navel-gazing is fun every once in a while. If you use Wordle, be aware that it thinks “example” and “examples” are different words. It also thinks “Example” and “example” are different words.

The next release of Apple’s OS is code-named Snow Leopard. It will include OpenCL:

OpenCL (Open Compute Library), makes it possible for developers to efficiently tap the vast gigaflops of computing power currently locked up in the graphics processing unit (GPU). With GPUs approaching processing speeds of a trillion operations per second, they’re capable of considerably more than just drawing pictures. OpenCL takes that power and redirects it for general-purpose computing.

That’s interesting: in the history of computing, people first added GPUs to offload a certain kind of processing work onto specialized CPUs. Now we’re taking some of that processing power back.

The kidney, if I remember Dawn’s description of it right, works in stages. One stage adds too much water into the urine, but a later stage takes some back out. Why the kludge? Probably for historical reasons: if you’re a fish, being wasteful with water is not a problem. Crawl up onto land, and suddenly it is a problem. How to solve it? Add a patch to undo what an earlier stage does.

OK, so they’re not exact parallels. But stories like that are a way to remind myself of that useful quote, originally (I believe) from Kenneth Boulding, made a meme by Gerald Weinberg: “Things are the way they are because they got that way.”

Forgetting that is a problem, because we all tend to be Panglossians, thinking the thing we’re looking at is not only tuned to a problem but also optimally tuned. It may be bad but, well, I guess that’s just because bad is the best it can be.

If we realize it got to be what it is by a historical path, influenced by chance, we can be more ready to make change—and more ready for two reasons: not only is a historical accident unlikely to be really optimal, our change will be only one in a long history of changes and so it’s not that important that it be right. We can also realize that we have at least two options: to add something on, or to take something away—and that the latter approach is more likely to be under-explored and so more fruitful.

Book site

I notice from the registration page that there are only 68 early bird slots left for Agile 2008. That means the price will go up USD200 pretty soon.