We’ve talked about Zero, and One, so all that’s left of the big Three Numbers is “many”.

Many is more than one. More than one object that must be used in the same way, more than one implementation of an algorithm, more than one implementation of an interface. An API wrapper implemented once for production, and once for testing is Many. One real object and one mock is Many.

Clarity of code is a signal-to-noise ratio. We need our code to be as concisely meaningful as possible (not as cramped and crowded as possible, and not unnecessarily spread out over many pages). Whatever size provides the most accurate and quickest reading for trouble-shooting and enhancement is the best size.

Consider this quote from Dave Thomas (of the Pragmatic Programmers) on AOP (aspect-oriented programming, a.k.a. aspect-oriented software development - AOSD) :

Once you have decent reflection and metaclasses, AOP is just part of the language.

People who work with dynamic languages don't see any need for AOP-specific facilities in their language. They don't necessarily dispute the value of AOP for Java, where metaprogramming facilities are weaker, but for them, AOP is just a constrained form of metaprogramming. Are they right?

Last week, I attended the Aspect-Oriented Software Development 2007 Conference in Vancouver, BC, where I gave a tutorial on aspect-oriented design and a paper in the Industry Track, also about design.

AOSD and this particular conference are still mostly academic projects with some notable industry traction, especially in the Java world. It is also a technology that needs to break through to the next level of innovation and applicability, in my opinion.

I posted earlier about the three numbers of software design (zero, one, many). Zero and Many are numbers we see pretty often, but the rise of TDD has made “one” just a little bit lonelier. I wanted to say that one is the loneliest number, but David Chelimsky beat me to it several months ago, and I would just feel like a copycat.

When we’re test-driving an application into existence, we tend to create mock objects. The presence of one mock object in addition to one real object places is firmly in the design space of “many”, and so interfaces become the rule of the day.

In addition, we have dependency management to deal with. In order to reduce the D metric on a package, we find ourselves often breaking a class into an interface (increasing A) and an implementation that depends upon it (increasing I) in a separate package.

Of course, the “other question” is volatility. If we have one implementation of something small and simple in a domain that is very stable then we don’t need any interface and “one” takes center stage. This is true for whole value objects (fowler) in general. If the class is more complex, or dependent on special hardware or changing algorithms, then we end up creating a mock (driving us back to “many”).

But the number one is becoming more and more rare in our design world.

There are only three numbers that are truly meaningful in software design. The numbers are the same as the numbers in relational database design: zero, one, and many.

People say “we don’t do iterative”. Sometimes it is a prideful thing, more often a kind of self-effacing confession. However, you and I know that it’s not true. All software development is iterative, it’s a matter of granularity.

When working on the very first 1.0 release of a product, developers and managers may think that they’re not doing iterative work, but any idiot knows that they’re not writing all the code at once. They couldn’t possibly. They’re not releasing yet, but they’re appending functionality every day.

They try to design all at once, but that’s just for 1.0. Software is like a plan: it never survives contact with the real world unscathed.

After 1.0 do we cancel the project? If so, it’s a failure. After 1.0 is 1.0.1 or 1.1 or 2.0. The project continues and continues to receive new appendages and improvements. Isn’t the whole idea of “next release” an iteration?

Since you’re really iterating anyway, why not capture the data that iterating produces, and why not take advantage of the integration and testing opportunities that iterating will give us? And why not have useful feedback loops? And why not measure our progress as we go? And for that matter, why not go for smaller measured periods so we can judge trends more reliably?

When we say “it isn’t an incremental and iterative effort” we are really saying that we’re denying a basic truth, and choosing not to use the data it produces for us. Not intentionally, but almost certainly.

We finally released RSpec-0.8.0 today. Check out the rspec website for details.

Happy Spec’ing!

One of the more annoying problems in code, confounding readability and maintainability, frustrating test-writing, is that of the multidomain variable.

I suppose somebody forgot to clue me in to the Great Variable Shortage that is coming. I have seen people recycling variables to mean different things at different times in the program or different states of the containing object. I’ve witnessed magic negative values in variables that normally would contain a count (sometimes as indicators that there is no count, much as a NULL/nil/None would). I might be willing to tolerate this in programming languages where a null value is not present.

Yet I have seen some code spring from multidomain variables that made the code rather less than obvious. I think that it can be a much worse problem than tuple madness.

There is a spirited discussion happening now on the ruby-talk list called Oppinions on RCR for dup on immutable classes (sic).

In the core Ruby classes, the Kernel module, which is the root of everything, even Object, defines a method called dup, for duplicating objects. (There is also a clone method with slightly different behavior that I won’t discuss here.)

The problem is that some derived core classes throw an exception when dup is called.