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

Codemotion Magazine

We code the future. Together

  • Discover
    • Live
    • Tech Communities
    • Hackathons
    • Coding Challenges
    • For Kids
  • Watch
    • Talks
    • Playlists
    • Edu Paths
  • Magazine
    • AI/ML
    • Backend
    • Frontend
    • Dev Life
    • DevOps
    • Soft Skills
  • Talent
  • Partners
  • For Companies
Home » Frontend » Web Developer » Concerning Modules – how the lost wisdom of the ‘70s helps us today
JavaScript

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

facebooktwitterlinkedinreddit
Share on:facebooktwitterlinkedinreddit

Tagged as:Codemotion Amsterdam

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

Related articles

  • JavaScript: A First Look at the Type Annotation Proposal
  • Svelte: Why Is It an Innovation to Javascript Frameworks?
  • 5 JavaScript Frameworks to Follow in 2022
  • 6 Ways to Implement Metaprogramming in JavaScript with Proxies
  • Increase Your Speed and Efficiency With These 20 Incredible JavaScript Tips and Tricks
  • The Ultimate Guide to JavaScript | Learn JS to Grow Your Career
  • Best JavaScript Alternatives for Web Developers
  • Learn JavaScript – Take These Courses and Certificates
  • Top 7 JavaScript Books for Every Skill Level
  • Top JavaScript IDE to Use in 2021

Primary Sidebar

Lessons Learned in the Cloud

Dive deep into this whitepaper dedicated to the Cloud and discover more about Kubernetes.

OVH Logo Lessons learned in the cloud

Codemotion Milan 2022

https://youtu.be/ym8iilUy_U0

Latest Articles

Video: How to Use Python for Async Microservices

Microservices

AWS amplify, angular, AWS

Step by Step: Running Angular Applications in AWS

Cloud

django python framework

Top Trending Python Frameworks Today

Languages

serverless cloud

Video: Beyond Serverless Functions

Cloud

Discover More

  • Jamstack: Are Static Sites a New Revolution for the Web?
  • Why Companies Are Implementing the Developer Experience Job Position
  • Video: A JavaScript Developers Guide to WebAssembly (with AssemblyScript)

Footer

  • Magazine
  • Events
  • Community
  • Learning
  • Kids
  • How to use our platform
  • Contact us
  • Write for Us
  • About Codemotion Magazine
  • 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

Follow us

  • Facebook
  • Twitter
  • LinkedIn
  • Instagram
  • RSS

DOWNLOAD APP

CONFERENCE CHECK-IN