“Stop Refactoring” : A hyperbolic and incoherent lecture on a misunderstanding of aesthetics

A few months ago, Nat Pryce gave a talk entitled “Stop Refactoring!” It would have been much more aptly titled “Be careful you don’t refactor too much”, and a much shorter lecture if Nat had left out his odd views on imperial Japanese aesthetics.

I have a few problems with this talk, not all of them in some coherent structure. Of course, the talk itself did not seem to be driven by any sort of coherent structure, so I guess my criticism will just be a reflection of that.

The Value of Code

Nat brings up an opinion I sometimes see unsheathed by some in the software counter culture community that pretends a modicum of business knowledge but instead is just naivety becoming of a future PHB that things productivity = overtime. That is, the main purpose in software is to “make something useful for the people who are paying for it.” This is just untrue.

The main point of for-profit software is to, wait for it, make a profit. The main point of not-for-profit software like open source is to do whatever the hell you want as the author. Nat is mostly talking about for-profit software here, and he makes one of the standard naïve blunders anyone makes when they start talking about business concerns without any actual training – revenues equal profits. I’m pretty sure when stated so bluntly, most can see why that is not true. Nat is not the first person to argue this implicitly, you can see it as a fundamental assumption in  a lot of (primarily marketing or sales driven) enterprises.

The part left out, cost, can be dismissed with so much hand waving and all kinds of crazy ass ideas come out of the woodworks, such as ‘stop refactoring’. Refactoring, design, architecture and all the ‘backroom’ activity that software developers routinely do adds no value to the customer. But it does add value to the enterprise. It controls costs.

Well designed code, which is the goal of the practice of refactoring, controls costs in two ways:

1)      Maintainability

1. Organizations with a complex code base pay a premium per hour of development labor.
2. Poorly designed code usually is caused by rapid developer turnover. Turnover is incredibly costly, especially in ‘creative’ pursuits like software.

2)      Extensibility

1. The cost to the organization of adding a new feature is dependent on the complexity of the software the feature is to be added to.

To sum up, as stated before on this blog, features are not the only thing driving profit and refactoring cuts cost. There are managerial gurus who will tell you LEAN will save your company, or focus on the customer will save your company. They occasionally convince a developer that focus on design or the customer is the key to business. This is false. The key to business is to constantly be optimizing the changing equation of what you can do (costs) and what they need (revenues).

Minimalism is not endogenous

Nat goes on to criticize minimalism as being artificial, and for its aesthetic infecting software. He misunderstands minimalism and the exogenous circumstances that lead to it being adopted.

Minimalism didn’t come from no where. It came up in a particular time, with a particular purpose. During the late 18^th century, building architecture was being revolutionized by steel. Buildings could be built higher and bigger, with less and less concrete façade. Designing these large buildings – each bigger than the last – was new and time consuming. For a single dollar of an architects labor, you could either get more ornamentation or more size. Thus, minimalism arose from the conscious choice of designers to focus on scaling up rather than ornamentation.

Of course, again, if you simply hand wave this away, Nat’s argument makes sense. Why did we let this stinky old modernism into software, software should be like a comfortable leather jacket! But when you realize minimalism is an aesthetic virtue that yields a large multiplier on your ability to scale, it becomes obvious why software is so amenable to being judged by minimalist standards.

Nat seems to imply that the relationship between architecture and software is as old as architecture itself. I’d instead argue it’s a relatively new phenomenon. I’d say the first major realization that architecture and software had a lot in common was after the book Design Patterns by the GoF, who first published a widespread recognition that the two arts were similar.

What that means is that our idea and feelings for aesthetic minimalism and elegance in our code was independently discovered in software in the 1960’s, apart from the same aesthetic in building design. That, to me, boosts the argument that there was a reason minimalism worked in software as well as architecture.

As Nat himself argues, software is subject to change. It is subject to massive growth. It must scale easily. Well designed application software is extended much easier than poorly designed application software. But more important to software scale, Nat makes the point that minimalism also was pushed for mass manufacture of things. He says so distastefully, but we must remember that most of our codebase when fully compiled into object code is ‘manufactured’ code. It’s library code. It’s code that was nothing more than standardized parts of vectors, dictionaries, folds and filters plugged together in a new and arbitrary way to make an application. Minimalism in API design isn’t just a good aesthetic principle – it’s absolutely required to be a successful library. Compare the reusability of the standard template library of vectors and algorithms in C++ towards the reusability of a more baroque library, C++ strings or even worse, C++ IOStreams.

When form follows function, it is very easy to intuit function from form. And when all a developer has is your API, she needs to be able to have an easy way to figure out how to use it. A clean, elegant API is easier to learn and immediately capitalize on a new project.

I won’t even get in to Nat’s odd understanding of 15^th century Japanese artifacts. Besides the fact that, of course they were hand made, there were no alternatives. Oh, and also the fact that he doesn’t seem to separate out the age intrinsic of a 300 year old artifact versus an 80 year old building, but instead credits the 15^th century designers for letting the object age so well.

Nat’s final point regarding aesthetics is oddly self defeating. He begins to talk about beautifully worn leather belts and jackets. I can understand some of his argument that a code base can be a reflection of who has worked on it much like a well worn belt has distinct patterns of oils and wear. But the fact is vintage apparel only exists today as objects of aesthetic judgment precisely because someone maintained them! If I don’t take CARE of my nice leather jacket in the 1950’s, it won’t be a beautifully worn vintage jacket in the 2010’s! If you don’t take care of something, it wears out rather than wearing beautifully.

In a talk titled “Stop Refactoring!”, this is the equivalent of saying “Look at this wonderful old code I found. We should stop refactoring so our code will look this old more quickly!”

The complete and utter insanity of hyperbole

My final criticism is of a practice that I, myself, have taken part in. But it has become more and more prevalent since Dijkstras original paper, “Goto’s considered harmful”, which is ironic since the title of that paper was intended to be an understatement rather than hyperbole.

We have got to clamp down on this practice of using inflammatory titles, subject headers or political platform statements just to get hits and views. Nat gives the impression, near the end, that he understands the value of refactoring, he’s just instead arguing we may be refactoring too much at times. This is a view I completely agree with. It’s one we can use the same cost argument I mention above in debating – is this refactor worth it in terms of saved costs? But instead, Nat adds to the debate that we don’t need any refactoring. Indeed, he leads off with the argument that we should stop altogether.

When your title emphasizes how we need to stop doing something, and most of your talk is about how it’s useless, it’s hard to then counter argue at the end of your lecture that hey, this thing I told you to hate, well, yeah, a little bit is okay. I’d even suggest you do it regularly! It makes no sense.

The title of this talk would have made much more sense if it were merely “Don’t refactor too much”, or even if you wanted the same comedic effect, “Don’t refactor (too much).”

What did this add to the conversation?

Well, I thought a bit more about minimalism in software design and was forced to come up with a good defense for it, so I suppose Nat’s talk was thought provoking in that way. But I certainly think it did more harm than good in the constant developer versus manager struggle over whether the code needs to be cleaned up. It did so due to a naïve understanding of business to begin with, and thus I think it was a bit dangerous. Someone is running with scissors.