PragDave

Fifth installment of Bill Venners' Interview

The fifth installment of Bill Venners’ interview with Andy and me is all about building adaptable systems. The previous article generated an enormous thread (still running) of negative comment in the Extreme Programming mailing list. This one will probably generate death threats…

Dave and Andy Trampled By Raging Hordes of XP Programmers

Bill Venners has posted the fifth article extracted from an interview he did with Andy and me in Portland. This one’s about our assertions that you should "Put abstractions in code, details in metadata." Reading the transcript, we come off dissing XP a fair amount; YAGNI comes in for some criticism. We claim that it’s OK to use experience to predict which parts of a system will be volatile, and it’s OK to build in support to handle that volatility (particularly by using metadata to describe the details of the application). I’m expecting a lot of e-mail on this one… :)

Artifacting

Software development is a discipline of artifacts; for a bunch of folks who like to do things, we seem surprisingly wedded to nouns, not verbs. Just look at the vocabulary of methodologies: requirements, designs, quality, communication, tests, deliverables—all good solid things. And yet increasingly I’m realizing that these things, these nouns, are not really all that useful. Let’s look at just two of them (for now), requirements and quality.

The value of spending three months doing a requirements analysis is not the 150 page document that is produced. It certainly doesn’t capture the full nuance of the system, and it’s just about certain that it will gradually become outdated as the project butts up against reality and the implementation adapts accordingly. No, the value of requirements is not the deliverable document, the artifact. Instead the value is the process that everyone goes through in order to produce the document: the understanding gained, the relationships forged, the negotiations, the compromises, and all the other little interactions which share information.

Quality is another terribly important word. We plan it, measure it, hire folks to manage it, and put big posters about it on our walls. But again, quality should not be a noun: you can’t measure it, or draw it, or describe it. Quality is a part of the process; it’s in the doing. Quality isn’t a set of rules, or a set of metrics. Quality is in the spirit of the smallest of our daily activities.

Once I started thinking about this as a pattern, it started to change the way I look at many of the other artifacts we produce (including the delivered programs themselves). Often the true value of a thing isn’t the thing itself, but instead is the activity that created it.

So, a challenge. Think of some of the common nouns we deal with on a daily basis (test, UML diagram, and architecture might be interesting starting places). Then try to recast them (somehow) as verbs. Where do you find the value? Should we be emphasising the doing of things more, and the artifacts less? How?

RubLog Now Supports If-Modified-Since

I ran a quick analysis on my access_log yesterday and discovered I was sending about 60-80Mb per day from the blog. So… a quick hack and the RSS feed now supports If-Modified-Since and sends 304’s back if nothing’s changed. Hopefully that’ll get me some bandwidth back :)

Adding Searching to the Blog

Chad Fowler (www.chadfowler.com) got me interested in searching when he published an article on Latent Semantic Indexing (here). Between us we dinged around with the simple part (building the vectors and calculating cosine differences between articles). The interesting part, using Singular Value Decomposition to cluster articles into What’s Related groups is currently beyond my rather pathetic math (somehow I seem to have managed to have either skipped or forgotten any classes on matrices). However, in the meantime it turns out to be rather easy to use the word vectors to implement straightforward searches of the blog. So, while I’m waiting for someone who knows what they’d doing to explain the SVD computation, I’ve made the simple search facility available as a plug-in for the sidebar.

Third installment of Bill Venners' Interview

The third installment of Bill Venners interview with Andy and me is now online. My favorite line is Andy’s: "Having a quality officer is kind of like having a breathing officer." Bill really does a remarkable job of taking our ramblings and rendering them down into something that might almost be considered coherent. He’s a nice guy too: have a look at the stuff on his site, www.artima.com.

The rOOts Conference

I just discovered that I'll be giving "How to keep Your Job" as a keynote at this year's rOOts Conference. This came as something of a surprise: I hadn't actually realized that I was invited. It'll be good: rOOts is a great conference: it is nice and intimate, the audience and speakers have a wonderful time, and Bergen is a great town.

One of my New Year's resolutions is to try to plan the conference trips better. Traditionally, I travel somewhere, do the conference, travel back, and then two weeks later get an e-mail from some company in the conference city saying "oh, we wish we'd known you were going to be here." Perhaps there should be a site where speakers can register their itineraries. In the meantime, it looks like I'm going to be in Norway in early May if anyone wants to meet up.

Topless Systems, Naked Objects

When talking about the failings of top-down development, Bertrand Meyer says "Real systems have no top.’[1] And yet the GUI-based applications we produce run counter to this: our code typically does have a "top," at least from the user’s perspective. The top in this case is the user interface, the collection of mini-scripted activities that we provide to allow our users to interact with our underlying application. Everything else in a typical interactive application is there simply to support this GUI, and this affects the way we both design and implement the code.

Interestingly, Naked Object applications (www.nakedobjects.org) do not have a top in this sense: the user is instead presented with a group of business classes and business objects. The user is free to interact with them in any way that makes sense.

If Meyer is correct (and I think he is), then Naked Object systems do indeed seem to be closer to the true spirit of OO development.

---

_[1]_ Bertrand Meyer, Object-Oriented Software Construction, 2nd ed

Bill Venners Interview

Andy and I were in Seattle in January for Scott Meyer’s Code Quality get together. Bill Venners took the opportunity to interview the two of us for his online magazine. The first of eight installments(!), a discussion of broken windows, is at www.artima.com/intv/fixit.html.

Io, Io, it's Off to Play I Go

Call me slow, but I hadn’t come across the Io language before today. I popped over to its site (www.dekorte.com/software/c/io/) and played for an hour. It seems to have a lot going for it:

• full OO (like Smalltalk)
• very simple semantics (even assignment is a message)
• nice orthogonal structure
• very compact
• fast enough
• different enough to be interesting, similar enough to be easy to learn

You can even get Io T-shirts and mugs at www.cafeshops.com/IoLanguage (what else do you need in a language?).

Io’s objects are generated by cloning existing objects, rather than instantiating classes (so it has some similarity to Self). So I could create a Dog object using something like

  Dog = Object clone
  Dog sound = "woof"
  Dog bark = block( write(self sound, "\n") )

  Dog bark

The first line creates a new object based on Object, assigning it to a slot called Dog. The second creates a slot in Dog called sound and arranges for it to reference the string "woof". The third lines creates an anonymous block (which writes "woof") and assigns that block to the bark slot in Dog. Finally we call it.

We can now create some objects based on a Dog: note that the mechanism is the same:

  rover = Dog clone
  fido  = Dog clone

  fido  bark              #=>  woof
  fido sound = "bow wow"
  fido bark               #=>  bow wow
  rover bark              #=>  woof

Io has differential prototyping: the only slots created in sub objects are those specialized in those objects.

Io has lots of interesting features. It keeps its code lying around in a message tree structure, allowing you to inspect and alter it at runtime (yup, alter. You can write self-modifying Io programs, so I guess adding aspects would be fairly straightforward).

Because it’s becoming a tradition, here’s 99 bottles of beer in Io (taken from the distribution).

  bottle = block(i,
    if(i==0, return "no more bottles of beer")
    if(i==1, return "1 bottle of beer")
    return i asString("%i") .. " bottles of beer"
  )

  for(i, 99, 1,
    write(bottle(i), " on the wall, ", bottle(i), ",\n")
    write("take one down, pass it around,\n")
    write(bottle(i - 1), " on the wall.\n\n")
  )

I’m not sure if Io is a keeper for me. It is certainly interesting, but it has a slightly pedantic feel to it (especially compared with Ruby). But it’s fun to play with.