Comments and Style

Here's a small fragment I've just spotted in The Elements of Java Style.

if (this.invoiceTotal > 1000.0) {
    this.invoiceTotal = this.invoiceTotal * 0.95;
}

The authors say that the program appears to give a 5 percent discount. And again in the comment (the tip is on writing comments) they point out that:

// Apply a 5% discount to all invoices 
// over one thousand dollars

is a valueless comment because it provides little additional information. Maybe. But it does provide some additional information. I count three things the comment says that the code doesn't. One is the % symbol, two is the word discount, and three is the word dollars. The point is you can say these three things in the software itself. For example:

if (this.invoiceTotal > 1000.0) {
    final double discount = this.invoiceTotal * 0.05;
    this.invoiceTotal = this.invoiceTotal - discount;
}

To my eyes the repetitive this. is just noise, so I would simplify to:

if (invoiceTotal > 1000.0) {
    final double discount = invoiceTotal * 0.05;
    invoiceTotal = invoiceTotal - discount;
}

and then to:

if (invoiceTotal > 1000.0) {
    final double discount = invoiceTotal * 0.05;
    invoiceTotal -= discount;
}

Say it in software. Less code, more software.

I've received some feedback on my initial post - which is nice. Ric Parkin advised caution about drawing analogies from The Quantum Self - mostly because any analogy, when stretched too far, will snap. And I agree. Analogies can be useful but you musn't forget that software is a discipline in its own right.

So to expound a little, when I was thinking of the particle/wave analogy I wasn't thinking of the dynamic aspect, the interaction - I was likening the particle aspect to the inside of an entity and the wave aspect to its connections to the outside. The shape. The fractal shape if you like (since I'm also reading Chaos). Shape is important. Richard Gabriel talks about shape quite a lot in his excellent book Patterns of Software.

Kevlin Henny (who incidentally, coined the phrase "less code more software") also had some insightful comments on the word follows in "form follows forces". It suggests moving only in one direction, and we all know this is not the case. Developing software is not a linear process. Feedback is natural and healthy. If there was a word that conveyed follows-and-is-followed-by I'd use that. But I can't think of one.

Particles and Waves

I'm reading The Quantum Self by Danah Zohar (ISBN 0-00-654426-6). There are lots of passages that remind me of aspects software development. Or rather, aspects of software itself. In particular, during my consultancy travels I notice that a lot of software shops pay too much attention to the individual bits of software and not enough attention to the way the bits are connected together. The connections are everything. As Fred Brooks said (in The Mythical Man Month):

The essence of a software entity is a construct of interlocking concepts

Anyway, back to The Quantum Self and the snippet that grabbed me:

each sub-system maintains some identity through its particle aspect and merges with a new and larger identity through its wave aspect.

The particle aspect reminds me of the individual bits and the wave aspect reminds me of the interlocking. Neither is more important. A quality design needs both. Poor designs are typically wave-aspect-poor. Same for books. A lot of books on, for example, C++ focus on the particle aspect of C++. They give you lots of small code fragment and detail on syntax but almost nothing on the bigger picture; on how to design the stuff to fit together and how to use C++ idiomatically to reflect the design.

I'm also reading Chaos by James Gleick (ISBN 0-349-10525-1). There's a bit in it that reminded me of something Kevlin Henney said in one of his presentations. He (Kevlin) was discussing Patterns (in the Chrisopher Alexander-Richard Gabriel sense rather than the Gang of Four sense) and in particular the idea of forces. Gleick (quoting D'Arcy Thompson) asks:

whether all the patterns might be reduced to a single system of generating forces.

In my copy of Chaos I've scribbed "form follows forces". I mean this as a replacement to the idea of "form follows function" (which is a sound-byte I've never agreed with). Forces are important. In my mind they relate to the particle-wave duality I mention above. The forces come from the wave aspect. From how the parts interconnect. From the design. To quote Eliel Saarinen

Always design a thing by considering it in its next larger context.

This is one reason testing is so important. Testing forces you to use things. Using something forces you into the next larger context. This won't (despite what some say) magically make designs appears all by themselves but it does put you in a good place to think design thoughts.