Douglas Crockford describes himself as the Godfather of JavaScript. When I saw he was giving the main keynote at Codemotion Amsterdam, I knew we were in for an interesting talk, and I wasn’t disappointed. Rather than talk about JavaScript, Douglas chose to concentrate on a more fundamental aspect of coding, namely modularity.
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:
- Projects running over-budget
- Projects running over-time
- Software was very inefficient
- Software was of low quality
- Software often did not meet requirements
- Projects were unmanageable and code difficult to maintain
- Software was never delivered
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.”
Why modularity helps
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:
- Confinement of errors. An error inside one module (shouldn’t) break the whole system.
- More efficient development with large teams.
- Simpler (and more effective) testing since modules can be tested individually.
- Portability of modules between projects and code reuse.
- Secure boundaries between modules.
But what makes a good module? To answer that, Douglas presented us with: The Lost Wisdom of the Seventies.
Cohesion and Coupling of modules
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.
Object-oriented Programming
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:
- Exception coupling.
- “Banana” coupling (you want to use the banana, but you inherit the gorilla that is holding it along with the whole forest!).
- Inheritance coupling.
- Member coupling.
- Getter/setter coupling.
- Type coupling.
“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.
Levels of modularity
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:
- Subroutines (procedures, methods and functions).
- Objects.
- Packages (external files, libraries and frameworks).
- Processes (Unix pipe tools).
- Services (key in today’s *aaS world).
How to deliver good services
In the world of everything as a service, services have become the new modules. So how can we deliver good services?
- Services should be organised as actors.
- They should have strong functional cohesion.
- They should be loosely coupled.
- Services should pass messages securely, using JSON over TCP/IP (note, not over HTTPS!).
- Services can include secure service addresses in their messages.
Solving today’s software crisis
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.”