Douglas began by taking us back in time to October 1968 and the NATO Software Engineering Conference, held in Garmisch, Germany. This was notable as it was the first use of ‘software engineering’. In the conference report, they identified a key problem, which they dubbed the Software Crisis.
According to Wikipedia, this crisis was characterised by:
Although it’s no longer used as a term, a show of hands proved that we still suffer from the same problems today. As Robert M. Graham said in his talk at the ’68 NATO conference:
“We build systems like the Wright brothers built airplanes – build the whole thing, push it off the cliff, let it crash, and start over again.”
The problem is, software isn’t like other forms of engineering. One simple bug can be catastrophic for a piece of software. As a result, creating working software tends to be an iterative process. Which brings us on to the main subject of the talk, modularity. If you are creating large, complex systems, it is sensible to treat them as a series of smaller modules. Modularity is good because it allows:
But what makes a good module? To answer that, Douglas presented us with: The Lost Wisdom of the Seventies.
One of the key aspects behind modularity is information hiding (first described by David Parnas in 1972). Information hiding is about hiding design decisions taken inside a module. This idea was expanded on by Glenford Myers and Larry L. Constantine. They came up with two measures for how good the modularity of a system is. Cohesion and Coupling.
Cohesion, or relatedness, is a measure of whether a given module should exist. This starts with coincidental – it’s purely a coincidence that a piece of code emulates the functionality of another piece. This is a bad reason to create a module. At the other end of the scale, you get functional relatedness. If two pieces of code are genuinely the same functionality, then you should make a module (this is why functional programming is so powerful as a concept).
Coupling, or connectedness, is how tightly modules are related to each other. Tight coupling is bad. Fortunately, modern compilers prevent the worst form of coupling (namely content coupling.
One of the early attempts to enforce modularity in programming was Alan Kay’s Smalltalk language. This introduced the concept of object-oriented programming. In the ideal OOP, everything is an object and objects communicate by passing messages. Sadly, modern object-oriented programming languages have distorted this: everything is a class and classes communicate through members. This has created several new forms of coupling. These are:
“Unfortunately, inheritance–though an incredibly powerful technique–has turned out to be very difficult for novices (and even professionals) to deal with.” Alan Kay, 1993.
The next attempt to improve modularity was Scheme, Guy L. Steele and Gerald Jay Sussman’s attempt to capture Carl Hewitt’s Actor Model. The key thing here was the idea of levels of modularity:
In the world of everything as a service, services have become the new modules. So how can we deliver good services?
So, how can we actually solve today’s software crisis? Well, the key thing is to resolve the conflict between avoiding mid-project design changes and avoiding making unwanted software. Agile methodologies help here, but Douglas suggested that increasing the empathy of developers for their users is also important. This could include annual team sprints, where the developers are embedded alongside the actual end-users of their software. As Douglas said at the end of his talk:
“Make software for real people, not fictional characters.”