• Skip to primary navigation
  • Skip to main content
  • Skip to primary sidebar
  • Skip to footer
Codemotion Magazine

Codemotion Magazine

We code the future. Together

  • Magazine
  • Dev Hub
    • Community Manager
    • CTO
    • DevOps Engineer
    • Backend Developer
    • Frontend Developer
    • Web Developer
    • Mobile Developer
    • Game Developer
    • Machine Learning Developer
    • Blockchain Developer
    • Designer – CXO
    • Big Data Analyst
    • Security Manager
    • Cloud Manager
  • Articles
    • Stories
    • Events
  • Sign In
Home » Dev Hub » Web Developer » Concerning Modules – how the lost wisdom of the ‘70s helps us today
Web Developer

Concerning Modules – how the lost wisdom of the ‘70s helps us today

In Codemotion Amsterdam 2019, Javascripts Godfather Douglas Crockford delivered a keynote about the importance of modularity (not just in Javascript).

Last update December 1, 2019 by Toby Moncaster

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.”

Tagged as:Codemotion Amsterdam JavaScript

Ready, Steady, Crash! One engineer’s journey into the world of load testing
Previous Post
Blockchain in JavaScript with Lisk Alpha SDK
Next Post

Primary Sidebar

Whitepaper & Checklist: How to Organise an Online Tech Conference

To help community managers and companies like ours overcome the Covid-19 emergency we have decided to share our experience organizing our first large virtual conference. Learn how to organise your first online event thanks to our success story – and mistakes!

DOWNLOAD

Latest

What are the Main Areas of Development for Programmers to Land Their Dream Job? Codemotion

What are the Main Areas of Development for Programmers to Land Their Dream Job?

Backend Developer

How to Contribute to an Open-Source Project

How to Contribute to an Open-Source Project

Backend Developer

6 Great DevOps Metrics - and How to Choose the Right Metrics

6 Great DevOps Metrics – and How to Choose the Right Metrics

DevOps Engineer

Codemotion Interview with Chad Arimura

Thinking Like a Founder – meet Chad Arimura

CTO

DesignOps and UX Engineers

Move Over DevOps! Time for DesignOps and UX Engineers

Designer - CXO

Related articles

  • Why Should You Care to Learn TypeScript?
  • GraphQL Testing With Karate
  • Introducing a new and improved Twitter API
  • Speeding up innovation with Arun Gupta
  • 18 Books & Blogs Every Developer Should Read
  • Kick Off A React Project: CRA, Next.js or Gatsby?
  • Tips For Every Full-Stack Developer In 2020
  • Getting started with WebAssembly and Rust
  • Douglas Crockford and his book “How JavaScript works”
  • Shokunin of the Web

Subscribe to our platform

Subscribe

Share and learn. Launch and grow your Dev Community. Join thousands of developers like you and code the future. Together.

Footer

  • Learning
  • Magazine
  • Community
  • Events
  • Kids
  • How to use our platform
  • About Codemotion Magazine
  • Contact us
  • Become a contributor
  • How to become a CTO
  • How to run a meetup
  • Tools for virtual conferences

Follow us

  • Facebook
  • Twitter
  • LinkedIn
  • Instagram
  • YouTube
  • RSS

DOWNLOAD APP

© Copyright Codemotion srl Via Marsala, 29/H, 00185 Roma P.IVA 12392791005 | Privacy policy | Terms and conditions

  • Learning
  • Magazine
  • Community
  • Events
  • Kids
  • How to use our platform
  • About Codemotion Magazine
  • Contact us
  • Become a contributor
  • How to become a CTO
  • How to run a meetup
  • Tools for virtual conferences

Follow us

  • Facebook
  • Twitter
  • LinkedIn
  • Instagram
  • YouTube
  • RSS

DOWNLOAD APP

CONFERENCE CHECK-IN