Abstract nouns: symptom of poor writing

Sometimesamazingly often, in factthings I’m reading and thinking about seem to mesh, serendipitously, and fall together very nicely. I don’t know how to explain it, but it sure is fun.

A couple of weeks ago I wrote about abstraction, some of the problems it causes, and things we can do to help deal with it. Yesterday Dave Thomas wrote about nouns and verbs, and about how the nouns we use for certain things (quality and requirements in particular) tend to mask the processes of achieving those thingsthe verbs, in other wordsthat are where the real value is.

While reading Brian Marick’s response this morning, I suddenly remembered something I read several years ago.

Everyone who writes in English should, in my opinion, read Joseph M. Williams’ book Style: Toward Clarity and Grace. Here is an excerpt from the section of that book I remembered:

In addition to the influence of the Norman Conquest and the Renaissance, there has been another, more subtle historical influence on our prose style, an influence that some linguists have speculated to be a kind of stylistic destiny for literate societies. As societies become intellectually mature, it has been claimed, their writers seem increasingly to replace specific verbs with abstract nouns. It allegedly happened in Sanskrit prose, in the prose of many Western European languages, and it seems to be happening in modern English. What centrally distinguishes sentence (1) from (2) is […] the abstract nouns in (1) in contrast to the shorter and more specific verbs and adjective of (2):

  1. The Committee proposal would provide for biogenetic industry certification of the safety to human health for new substances in requests for exemption from Federal rules.
  2. The Committee proposes that when the biogenetic industry requests the Agency to exempt new substances from Federal rules, the industry will certify that the substances are safe.

These nouns alone make a style more abstract, but they encourage more abstraction: once a writer expresses actions in nouns, she can then eliminate whatever (usually concrete) agents perform those actions along with those whom the actions affect: The proposal would provide for certification of the safety of new substances in requests for exemption.These abstract Romance nouns result in a prose that we variously call gummy, turgid, obtuse, prolix, complex, or unreadable.

Yep. That sounds like most software documents. I think Dave and Brian are onto something.

The Context of Communication, part 2

(This continues thoughts from part 1.)

Brian really got me thinking about the nature of communication.

He lists several examples of how the “conduit metaphor” shows up in the way we speak about communication, and I thought of a really telling one from our field: Alistair Cockburn’s convection currents of information. But then, as I thought about it some more, that led me in some interesting directions.

We tend to tackle communication issues head-on. If we recognize that our communication isn’t working for some reason, we tend to address specific failings. Try to be more precise, or more thorough. Or more organized. Make sure things get disseminated to the right people. Have reviews to verify understanding and point out weak areas. And so on.

Part of the strength of XP and many other agile methods is that they don’t address the communication per se; instead, they address the context in which it occurs. They strive to make communication less formal, more frequent, more concrete, more serendipitous, and (tellingly, I think) more redundant. The key is understanding that people want to communicate, and we’re good at it, if the barriers are low enough.

So, back to Alistair’s metaphor. Although “convection currents of information” is clearly squarely in line with the conduit metaphor, it’s interesting that so much of what Alistair talks about is implicit, serendipitous communication. He talks about information radiators and other explicit channels, but the emphasis is on building a context where information simply flows, implicitly and effortlessly.

Update: Brian wrote a thoughtful response.

Java 1.4.1 for OS X, and the first bug

While I was downloading 1.4.1 yesterday, Greg Vaughn was reading the release notes and IMing me about them:

Known issues: no incremental gc :-(

What about concurrent?

It doesn’t say

That’s OK, really … incremental GC had serious problems in 1.3, and they weren’t fixed for 1.4; instead, nearly all of the GC work went into the concurrent collector, which arrived with Sun’s 1.4.1.

But I started wondering about the concurrent collector. It occurred to me that I could probably tell whether the concurrent collector was included by turning on verbose GC output and watching.

First, I ran the SwingSet2 demo with the default collector. I saw what I expected: lots of young generation collections, with full heap collections occurring just under 10% of the time. Then I tried -Xincgc, and saw the same behavior; the release notes were telling the truth about the incremental collector.

With the -Xconcgc option, I saw very different behavior. In some cases I’ve seen up to 500 young collections before any attempt is made at a full sweep. Looks like the concurrent collector is there.

But there’s a race condition. On 3 out of 4 runs, roughly, when it did finally attempt a full GC, I saw this:

[GC 14014K->14001K(58108K), 0.0069902 secs]
[GC 13975K->13975K(58944K), 0.0093674 secs]
[Full GC[Unloading class sun.reflect.GeneratedMethodAccessor4]
[Unloading class sun.reflect.GeneratedMethodAccessor3]
# HotSpot Virtual Machine Error, Internal Error
# Please report this error at
# http://bugreport.apple.com/
# Java VM: Java HotSpot(TM) Client VM (1.4.1_01-14 mixed mode)
# ShouldNotReachHere()
# Error happened during: generation collection for allocation
# Error ID: /SourceCache/HotSpot14/HotSpot14-14/src/share/vm/memory/generation.hpp, 346
# Problematic Thread: prio=3 tid=0x0fd9ecf0 nid=0xedc8c70 waiting on condition
Abort trap

The Context of Communication

Brian Marick writes wonderfully (as usual) about how requirements documents and tests communicate the same thing in different ways. The interesting point is that, although it’s difficult to see how tests communicate the necessary information, for various reasons they do so more effectively than a requirements document. It shouldn’t be surprising that we have a hard time convincing some people of that.

I’ve been thinking about a related issue for a couple of years now. In The Mythical Man-Month, Fred Brooks writes about “the project notebook”: the authoritative source for information about the project. And it sounds like such a good idea. It’s easy to see how that would work. It records important information precisely and directly.

It’s alsoas you begin to understand when you read Brook’s ideas for how to manage the project notebookincredibly unwieldy and inefficient. And while the notebook might (if you spend a lot of time and money on it) contain all of the important information, it’s highly unlikely that it would ever be completely understood, by the right people at the right times in the right ways.

It works much better to let the codethe system itself, plus executable testsserve as the project notebook. This is why iterative development is so important. The code is functional, and it gives us feedback about our understanding. (More importantly, it gives us feedback about our misunderstanding.) If we think we know something about how the system works, we try to write code that depends on that knowledge, and the system will tell us if we were correct. With the project notebook, on the other hand, we might not learn about our error until weeks or months have passed, by which time the ripple effects from our mistaken assumption will be tremendous.

Another common objection to agile styles of development goes something like this: “You mean you don’t document or model design decisions that come out of a meeting? Haven’t you ever been to a meeting where everyone thought they had reached an agreement, only to find out that each person understood the decisions differently?” Sure I have. But the problem there, I believe, is largely that people have a hard time communicating about abstract things. Handwaving, and even boxes and lines, aren’t really very expressive about what software is. I’ve been in a lot of those discussions, and the problem is that there’s almost no feedback about whether you really understand what’s being said. I’ve been completely confused and at the same time absolutely convinced that I understood everything.

When people have those same discussions in the context of codeworking codecommunication changes. It may seem strange to say this about software, but code is concrete. It’s unambiguous. It grounds our discussions in a reality, and it’s a terrific aid to effective communication and understanding. It provides a feedback mechanism for the act of communication. If you don’t understand what’s being said, then the proposal (more often than not) won’t make any sense when held up against the code.

It’s no wonder that, in many test-first teams, design debates are frequently carried out through unit tests. The “conduit” and “program” metaphors of communication each have their strengths, and the best policy is to let them support and reinforce each other.

More Stuff, Less Fluff

Most of my compatriots on the No Fluff, Just Stuff tour have blogged about the first symposium of the year, so I guess it’s my turn.

I’m excited that things are rolling again. These are excellent events for the attendees, and also for the speakers. I’m always energized and enriched by spending a weekend talking to the other speakers and the audience members about software topics. (You’ll notice that both the quantity and depth of my blogging has decreased during the break since the Atlanta symposium at the end of November. I expect it to begin picking up again now.)

This weekend in Austin I gave five talks. The two older talks (Introduction to XPath and Java Web Start and JNLP: The Return of the Rich Client) were both well received, and the three new ones went much better than I expected:

  • Concurrent Programming Utilities—I had a nice crowd for this one, and they were excited to learn about utility classes that can help them build better concurrent systems. More than one person said that they wished they had been to my talk a year ago, because it would have saved them a lot of grief.
  • Introduction to Aspect-Oriented Programming and AspectJ—I need to work on a better demo and a few more diagrams to help illustrate some tough concepts, but folks liked the talk anyway, and I don’t think I lost anyone!
  • Project Infrastructure Values, Principles, and Practices—This is my favorite talk of the bunch, and it also went really well. It ended up being about 20 minutes too short, which was unfortunate for this time, but it’s nice because it means I’ll have time for some demos and more in-depth information next time around.

I’ll be doing the same slate of talks at the Northern Virginia Software Symposium the last weekend in March. I can’t wait!

subscribe via RSS or JSON Feed