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
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 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
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.
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.
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.’ 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.
__ Bertrand Meyer, Object-Oriented Software Construction, 2nd
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’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") )
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
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.