« February 2003 | Main | April 2003 »
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… :)
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?
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.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
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:
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.
