SCNA 2011 Part 3: Gary Bernhardt, “Expansion and Contraction”

Also posted at

Gary Bernhardt took the stage to talk about the evolution of programming languages and technologies. He talked about the fact that languages and technologies evolve in waves: first there’s a wave of expansion where a new language comes along and increases the number of things we can do, and it is followed by a contraction that reduces the number of things we can do but also removes a lot of confusion and therefore enables us to deliver more reliable software with the new toolset.

So, expansion increases capability – our power to express an idea. Over time abundant resources and confusion drive change and we see a contraction that removes 5% of the capability and 85% of the confusion to enhance suitability – the power to deliver reliable software that works.

Many expansions are initially dismissed by the developer community. For example, looking back at Djikstra’s proposal for structured programming, it was met with the following review:

Structured programming is a nice academic exercise, which works well for small examples, but I doubt that any real-world program will ever be written in such a style.

The relational model was met with similar criticism and the same quote can be paraphrased and applied almost universally to new technologies coming out today. Instead of focusing on how something can’t possibly be workable, we should consider what larger purpose it may be serving: either by improving capability or suitability.

Here are some examples from history:

  • 1957: Fortran increases capability vs Assembly.
  • 1968: Structured programming increases suitability vs Fortran.
  • 1970: Relational model comes out as more suitable vs flat files.
  • 1985: C++ is more capable vs C by adding object-oriented concepts.
  • 1995: Java is more suitable vs C++ by removing some of the complexity and introducing automatic memory management.
  • 2004: Rails extends the capability vs existing ways to develop web applications.

Rails displays a culture of capability. The focus is on new gems and new features all the time and when something breaks, it’s easier to just move on to the new working thing than fix the broken one.

Gary made a point that capable systems generate a lot of activity (for example, the gem explosion in Rails), but then a contraction into more suitable tools creates suitable systems where the real progress happens. He described the difference between activity and progress as a developer who commits code lots of times a day but doesn’t necessarily produce a lot of value. That developer is certainly active but may not be making much progress.

So what happens after Rails? Gary suggested that there’s frustration building in the developer community and it’s likely going to lead to a contraction step. Up next are the functional revolution and outside-in top-down London style test-driven development. Which are, of course, impossible since they are nice academic exercises, which work well for small examples, but no real-world program would ever be written in such styles.

Leave a comment

1 Comment

  1. Great post… I think the path we’re seeing with Rails 3.1 and beyond does indicate a bit of a contraction step… the Ruby community definitely embraces Perl’s TMTOWTDI philosophy, but I think there is a desire for at least more guidance when it comes to standards and “best practices.” We’re seeing things like Devise, OmniAuth, and CanCan become ersatz defaults when it comes to authentication and authorization, for instance. The nice thing about the “gemplosion” with Rails is that libraries become subject to natural selection rather than selection by fiat. The most popular libs generate the most discussion and communisty-generated documentation/support, and the less popular ones eventually whither and die.

    I also think you’re spot on pointing out FP and outside-in TDD (which is really behavior-driven development) as the Next Big Things. And I think the Rails community is already on that badwagon; there’s a lot of discussion of applying functional styles in Ruby (which is not that hard to do, given its Lisp heritage), as well as use of BDD tools like Cucumber.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: