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?

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.

---

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.

---

Bill Venners has posted the fourth 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… :)

---

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…

---

In the seventh part of Bill Venner’s discussion with Andy and me, we’re talking about gardening as a metaphor for software development.

Thinking in terms of analogies is a useful way of extracting hidden meaning. Brian Marick and Ken Schwaber are co-hosting an interesting workshop at Alistair Cockburn’s Salt Lake Agile DevelopmentConference. I particular like the first phrase in the description: The Analogy Fest is an attempt to manufacture serendipity .

The eighth installment of Bill Venners’ interview of Andy and me is now online. We’re talking about tracer bullets, prototypes, and iterations. The key to tracer bullets is the feedback they give: they let you know how well you’re aiming in a real-world environment. Short iterations and lots of feedback are the software development equivalent.