Non-DRY specs are more maintainable because they are an excellent example of choosing duplication over the wrong abstraction, of writing code that posesses locality instead of compression, code that is simple instead of complex.

Got it?

I was walking around the neighborhood today and heard, to my pleasant surprise, a familiar voice on The Maintainable Software Podcast: Jeanine Soterwood!

Jeanine and Robby were talking about non-DRY specs:

I was working on a spec and had my usual let statements at the top of the file..one of the developers just asked nicely, "would you consider defining all of the variables within the spec itself (and removing the let statements)? Once I started doing that, I thought: I love this. I feel like it is so much easier to understand the setup and teardown of a spec.  And when you do have to go back and look at code you haven't looked at in awhile, everything is right there. I also work on one of the projects for Ruby For Good. There are a lot of new developers that come to that project who are often new to writing tests. It's so much easier for them if all of the setup and teardown is in that one test. It's much easier to follow and much easier to write the tests as well - they ask themselves what objects they need and just create them. Even though sometimes it is hard - you're repeating yourself many times because your tests are similar and you're repeating blocks, I really love it.

I am now a total convert to the non-DRY tests.

Thoughtbot even has a blog post about this topic.

This story woke me up!

You see, I’ve heard this story before. In one of Sandi Metz’s (now famous?) talks, she quipped:

Duplication is better than the wrong abstraction

You can read her great blog post where Sandi expounds.

For years I've referenced Rich Hickey's famous description of simplicity, and how it differs from cardinality, from his talk Simple Made Easy:

SIMPLE:

• One fold/braid

  • One role

  • One task

  • One concept

  • One dimension

• But not

  • One instance

  • One operation

• About lack of interleaving, not cardinality

He also says:

Complex things must be considered together

And, Richard Gabriel writes (in 1996!) about the difference between compression and reuse, in his excellent book Patterns of Software:

Most people agree that maintenance is a big part of the overall software problem, but to organizations whose survival depends on getting out new projects or products, the important issue is getting the new software done.

Within each organization writing a lot of software - and among many organizations writing a lot of software - it seems that a lot of that software should be reusable.

If code is reused, it is more likely to be well tested and possibly bug free, and even if it isn't, the maintenance of the various programs that use the reused code should be easier.

Objects are often related to one another in a particular way: one is just like another except for some additions or slight modifications.

In short, subclassing is a means of reuse.

Compression  is the characteristic of a piece of text that the meaning of any part of it is "larger" than that piece has by itself.

Compression in object-oriented languages is created when the definition of a subclass bases a great deal of its meaning on the definitions of its superclasses.

Compression is dangerous because it requires the the programmer to understand a fair amount about the context from which compressed code will take its meaning.

Maintaining compressed code requires understanding its context, which can be difficult.

The primary feature for easy maintenance is locality: Locality is that characteristic of source code that enables a programmer to understand that source by looking at only a small portion of it.

Compressed code does not have this property.

This problem is not unique to class-based compression but applies to any abstraction-based compression.

And about habitability:

Habitability is the characteristic of source code that enables programmers, coders, bug fixers, and people coming to the code later in its life to understand its construction and intentions and to change it comfortably and confidently.

Software has to be habitable because it always has to change.

Do you see the connections?

Abstraction is the process of identifying common patterns that have systematic variations; the abstraction represents the common pattern and provides a means for specifying which variant to use

Locality: Code that is easy to grok because it does not rely on larger context elsewhere

Cardinality: Having more than one thing

Complexity: Having multiple things intertwined with each other

Duplication: The same code, or similar code, in more than one place

Compression: Code that requires context to understand and change confidently

To synthesize:

Simple is habitable. Simple is maintainable.

Duplication is simple

Locality is simple

The wrong abstraction is complex

Compression is the wrong abstraction. Compression is complex.

And to bring it back:

Non-DRY specs are more maintainable because they are an excellent example of choosing duplication over the wrong abstraction, of writing code that posesses locality instead of compression, code that is simple instead of complex.

Got it?