How To Train Yourself To Think In Terms Of Modules


Friday, 9.52pm

Sheffield, U.K.

At times, the solution to a maze is to reduce it to embers and walk straight through the ashes. – Mary Doria Russell, Children of God”

There’s a chicken and egg sort of thing that also applies to creative work – does structure emerge from the work or is it imposed on the work?

I was listening to The Tim Ferriss Show podcast today and he mentioned that he had written the ultimate guide to writing a book – effectively setting out a playbook that you just needed to follow and he went on to say that hardly anyone ever actually followed the steps in there.

One of the points he made in the talk was that you should think about your book in terms of modules – so you could run excerpts for people to see.

The module stuff interested me.

I’m also reading a book published in 1986 called Programmers at Work.

It’s slightly strange to think that the tools I’m using to write the way I do were first written in the late sixties and early seventies – close to half a century ago.

So, researching this area is like uncovering history and learning stuff that you can use right now all at the same time.

It’s as if you unearthed an ancient cache of Saxon swords and they all turned out to be still bright and razor sharp.

Anyway, one of the people in the programming book, Butler Lampson, talked about the importance of interfaces.

If you do want to think in terms of modules there are two things you need to consider.

The first are the interfaces between the system and the outside world and the second are the interface between the main parts of the system itself.

A book, for example, has quite a simple interface.

Another now ancient book that I’ve picked up recently is Document Formatting and Typesetting on the UNIX System which talks about three major logical parts to a book – the front or preliminary matter, chapters and the end or reference matter.

If you were building a web application, on the other hand, you’d need to think about the login screens and the main pages you’d need for users depending on their roles.

The interfaces between the main parts of the system have to do with how information flows through and creates insight as a result.

The structure may be invisible in a book or an application but the quality of what you read and use will very probably depend on whether it exists or not.

At the moment, I’m working my way through another book that seems like it’s a random collection of sentences thrown together with headings sprinkled in to create a sense of order.

I’ve stopped reading and started skimming as a result.

Now, I shouldn’t judge because I’m not someone who starts with structure.

Structure tends to emerge from what I put down – it’s more organic and natural – for me anyway.

I remember a while back being taught in an English class how to use brainstorming to create a short piece.

What emerged from the logical arrangement of those ideas was a flat piece, a dead piece.

Something that had no life or rhythm or feeling.

It was writing by numbers, building with blocks and it just didn’t work.

So I ripped it up and started again and let things flow.

And that worked better – the teacher didn’t believe I’d written both pieces – but that didn’t matter.

The point is that starting with structure doesn’t work for me.

However, it does work for others and that leads to an interesting thought.

In some cases, people come up with a structure and then fill in the details.

In other cases, people start with details and work away until when they take a step back and look at what they have done a structure emerges from the work.

For both, the trick is making the structure invisible – either erasing the pencil marks after the drawing is done or moving things around to ensure that the elements are balanced and harmonious.

It’s hard to hold a lot of stuff in your mind.

It’s better to work on small pieces at a time.

Ideally five to seven pieces.

Which is why if you look at the diagram above you have 7 external interfaces and 7 system components for each external interface.

If you were to write something of consequence, you’d need around 49 pieces.

If each piece was around 1,000 words long you’d end up with around 50,000 words which interestingly is the size of most non-fiction books these days.

So I guess the trick to modular thinking is to reduce the number of elements at whatever level you’re looking at to a handful you can keep in your mind.

Each time either build up or break down the parts you need to construct each module.

That will make it easier to assemble the pieces – to create the interfaces that glue everything together.

And which, in the long run, will mean you’ll end up with something you can ship.

And maybe even be proud of.


Karthik Suresh

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 )

Twitter picture

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

Facebook photo

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

Connecting to %s

%d bloggers like this: