This title was the motto of the brilliant but controversial mathematician Carl Friedrich Gauss, and means few, but ripe.

Gauss would not publish his work until it was complete and he was entirely satisfied with its presentation. Much of his work was unpublished and a considerable amount of it was only discovered after his death.

Gauss had a very terse, minimalist and perfectionist style of writing. This was criticized for not sufficiently conveying the intent of the work, or in other words, not being expressive enough.

In defense of his style, he said “no self-respecting architect leaves the scaffolding in place after completing the building”.

The downsides of this style should be clear to anyone, yet the quality the work that he did produce was good enough to be remembered as one of the greatest mathematicians of all time. Bronshtein and Semendyayev described him as Princeps mathematicorum, the foremost of mathematicians.

Gauss was a true outlier. But for just about everyone else, we could not be successful with this style. We need to deliver and to regularly. We must not let ego hinder us from delivering for our customers.

I recently paraphrased Gauss and used it as a metaphor for clean code.

An architect does not leave up the scaffolding once he has finished the building.

This received a mixed response, and uncertainty about what I actually meant by this. In the context of programming, what does the building represent? And what does the scaffolding represent? How does it relate to test driven development? And what does this mean in the context of spike work?

To me, the building represents the final work that the user experiences. The scaffolding is any artifacts that detract from the user experience or from your fellow developers. Scaffolding is often required during construction of the work, but is not part of the work itself and a work should not be considered complete.

Because the concerns of your user’s experience and your concerns over the code can be very different, I will use the terms user scaffolding and developer scaffolding to clarify.

In Growing Object Oriented Software Guided By Tests, Nat Price and Steve Freeman distinguish these concerns as internal quality and external quality, with external quality being quality from the point of view of the end user.

Robert Martin was once asked what the best metric was for code quality? Should be very focused on measuring code coverage, or number of tests, or cyclomatic complexity, or halstead complexity, class coupling etc? No, the most important measurement of code quality is customer satisfaction. 

He went on to explain that there are two types of customer satisfaction: their satisfaction now, and their satisfaction a year from now, adding that if you don’t address technical debt then although they might be happy now, they won’t be happy a year from now.

User scaffolding is essentially any bugs in your code. In non trivial software, bug free code is rare, but there are many best practices that can help us to find and fix bugs

Developer scaffolding includes functions that aren’t being called from anywhere, variables that aren’t used, zombie code etc. Basically any of the bad practices that you can find in books like Clean Code or Code Complete.

As for unit tests, if they are actually useful tests (not just tests written to increase the code coverage stats and create the appearance of quality) then I don’t consider them to be scaffolding because they are serving a useful purpose.

And as for spike work, well I have heard the word spike used to mean a couple of different things. There is the “steel thread” meaning: a minimally functional end to end solution that later forms the basis of a complete solution. And then spike is also sometimes used for exploratory work that is done purely to gain understanding and is thrown away.

If the work is going to be thrown away (which is sometimes the best strategy), then you are not really architecting a building, at least not at this stage. You are just sketching out ideas, and I don’t believe the metaphor applies here.

If you are building a minimally functional solution that is going to be part of what you deliver to customers, then this should be free of scaffolding at the point when it is delivered.

When the Software Craftsmanship movement was in its infancy, it was criticized for being too much about developers indulging their egos and putting coding rules ahead of the interests of end customers. I think that these arguments were important ones. I also think that Sandro Mancuso responded to them well in his book The Software Craftsman.

One of the things I said in my developer on fire interview (out 9th May) was:

“you and your colleagues know your business better than anyone else”

You know your code better than anyone else, you know your business strategy better than anyone else, and you know your customers better than anyone else.

So I am certainly not going to preach about whether you should be more focused on shipping software or more focused on not delivering until the quality meets specific requirements: you know better than me! Be suspicious of anyone who talks as if they clearly know much better than you.

However for the average developer, a little of the “Pauca sed matura” mentality is helpful, but probably wouldn’t make a good motto. “Multa opera” would make a much better one.

So you might wonder why I’ve paraphrased a known perfectionist while at the same time advised against perfectionism? The main message I would to get across is clean code is useful because it lets you work faster. Working faster is good because it helps you deliver software faster.

Good craftmanship is not against the interests of your customer. It is entirely and precisely for the interests of your customer.