The Clean Code Blog

by Robert C. Martin (Uncle Bob)

The Churn

27 July 2016

Did you year about the guy who said goodbye to OO?

Oh no. Not another one. What did he say?

He described all the promises of OO, and how none of them had really been delivered, and that all the features of OO cost more than they were worth, and that functional programming was better and…

Sigh. Yes, I’ve heard it all before.

So, then, OO is finally dead, and we can move on.

Move on to what?

Why, to THE NEXT BIG THING of course!

Oh. – That. Do you know what it is yet?

I dunno, I’m pretty excited about micro-services; and I’m really keen on Elixr; and I hear React is really cool; and …

Yes. Yes. The Churn. You are caught up in The Churn.

Huh? What do you mean by that. These are exciting times.

Actually, I find them rather depressing.

Why? I mean, there are new technologies bubbling up every few days! We are climbing to ever higher heights.

Bah! All we are really doing is reinventing the wheel, over, and over again. And we’re wasting massive amounts of time and effort doing it.

Oh come on! We’re making PROGRESS.

Progress. Really? That’s not the way I see it.

Well, just what is it that you see?

I see waste. Massive, incalculable, waste. Waste, piled upon waste, piled upon even more waste.

How can you say that?

_Well, consider this OO issue. OO isn’t dead. OO was never alive. OO is a technique; and a good one. Claiming it’s dead is like claiming that a perfectly good screwdriver is dead. Saying goodbye to OO is like saying goodbye to a perfectly good screwdriver. It’s _waste!

But Functional Programming is better!

I’m sorry, but that’s like saying that a hammer is better than a screwdriver. Functional programming is not “better” than Object Oriented programming. Functional Programming is a technique, and a good one, that can be used alongside Object Oriented programming.

That’s not what I heard. I heard they were mutually exclusive.

Of course they aren’t. They address orthogonal concerns. Concerns that are present in all projects.

Look there are people who think that software is a linear chain of progress. That we are climbing a ladder one rung at a time; and that every “new” thing is better than the previous “older” thing. That’s not the way it works.

So, how does it work – in your opinion?

Progress in software has followed a logarithmic growth curve. In the early years, progress was stark and dramatic. In later years the progress became much more incremental. Now, progress is virtually non-existent.

Look: Assembler was massively better than Binary. Fortran was much better than Assembler. C was a lot better than Fortran. C++ was probably better than C. Java was an improvement over C++. Ruby is probably a bit better than Java.

Waterfall was a whole lot better than nothing. Agile was better than waterfall. Lean was a little better than Agile. Kanban may have been something of an improvement.

Every year. though we apply massive effort, we make less progress than the year before; because every year we get closer and closer to the asymptote.

Asymptote! You think there’s an upper limit to software technology and progress?

I absolutely do. What’s more I think we are so close to that limit now, that any further striving is fruitless. We are _well passed the point of diminishing returns._

What? That sounds ludicrous! That sounds depressing!

I understand. But that’s because we got used to all that early rapid growth. Those were heady days; and we want them back again. But they’re gone; and we have to face the fact that we are wasting time and effort on a massive scale trying to recreate them.

But if we don’t push for the future; we’ll never create it!

Believe me, I definitely want us to push for the future. That’s not what we are doing. What we are doing is pining for the past.

So what future do you think we should be pushing towards?

A productive one. A future that is not dominated by all this wasteful churn.

What’s wasteful about it?

Have you ever used _IntelliJ or Eclipse to program Java?_


Those are _incredibly powerful tools. A skilled professional can be wildly productive with those tools. The refactorings! The representations! The facilities! My God; those tools are spectacular!_

Yet every time a new language comes along we dash away from those powerful tools to use the NEXT NEW THING. And the tools for that new language are like programming in the third world. God, you often don’t even have a reasonable rename refactoring!

It takes _time to build up a reasonable toolset. If we keep on switching languages, we’ll never be able to tool those languages up._

But the newer languages are better.

Oh bull! They’re _different; but they aren’t better. Or at least not better enough to justify throwing our toolset back into the stone age._

And think of the training costs for adopting a new language. Think of the cost to the organization of having to use 84 different languages because the programmers get excited about shiny new things every two weeks.

Shiny new things? That’s kind of insulting isn’t it.

I suppose so; but that’s what it comes down to. New languages aren’t better; they are just shiny. And the search for the golden fleece of a new language, or a new framework, or a new paradigm, or a new process has reached the point of being unprofessional.


Yes! Unprofessional. We need to realize that we have hit the asymptote. It’s time to stop the wasteful churning over languages, and frameworks, and paradigms, and processes.

It’s time to simply get down to work.

_We need to choose a language, or two, or three. A small set of simple frameworks. Build up our tools. Solidify our processes. And become a goddam _profession.