A Sense of Unhurriedness

Martin Fowler: There's an impossible-to-express quality about test-first
design that gives you a sense of unhurriedness. You are actually moving very
quickly, but there's an unhurriedness because you are creating little micro-goals for
yourself and satisfying them. At each point you know you are doing one micro-goal piece
of work, and it's done when the test passes. That is a very calming thing. It reduces the
scope of what you have to think about. You don't have to think about everything you
have to do in the class. You just have to think about one little piece of responsibility. You
make that work and then you refactor it so everything is very nicely designed. Then you
add in the next piece of responsibility. I previously used the kind of approach you
describe. I'd ask, "What's the interface of this?" I've now switched and I much more
prefer incremental design.

Bill Venners: Well, I'll try it.

Martin Fowler: In many ways, you have to just try the process out for
a little while. It's best to try it out with someone who's done it before. Just do it.

Here's an example of incremental design that I ran into when writing Patterns of
Enterprise Applications Architecture Design. I needed to create an example in a
pattern about associative table mappings. If you have a many-to-many relationship in
memory and you need to persist that to a relational database, it requires an extra link
table, so you get three tables. There are multiple ways to pull that data back into memory
from the database. There is a simplistic way of pulling the data back that requires a lot of
select statements to be executed. There is also a faster way to pull it back. You can just
pull the data back in a single select statement. But then it's a bit more awkward to get the
data out and to unpack it into the various objects.

I created the example for that pattern using incremental design. I started by writing an
example that was hard-coded for three particular tables and two particular classes. I didn't
think about generalizing it. I just made a very specific, concrete example work. After I
got that working and had it passing its tests, I started refactoring the example to make it
more generally applicable. After a bit of time refactoring, I had a general mechanism. All
I had to do was write a tiny mapping class, and I could make the example work with any
tables and classes. I had a general purpose structure.

I found it much easier to do the concrete example first, then refactor that to the abstract
example, than to come up with the abstract example first and then apply that to the
concrete case. I also found it much more calm and unhurried, even though the process
went pretty swiftly. I constantly knew where I was and where I was going. I felt much
more in control of the situation. I didn't have that, "Am I ever going to make this code
work?" feeling.