Quotes About Modularity

Encapsulation says that, not only are you allowed to take a simpler view of a complex concept, you are not allowed to look at any of the details of the complex concept. What you see is what you get—it's all you get!

The concept of modularity is related to information hiding, encapsulation, and other design heuristics. But sometimes thinking about how to assemble a system from a set of black boxes provides insights that information hiding and encapsulation don't, so the concept is worth having in your back pocket.

Object-Oriented Design Heuristics (1996), Arthur Riel

One indication that a routine needs to be broken out of another routine is deep nesting of an inner loop or a conditional. Reduce the containing routine's complexity by pulling the nested part out and putting it into its own routine.

Dijkstra pointed out that no one's skull is really big enough to contain a modern computer program (Dijkstra 1972), which means that we as software developers shouldn't try to cram whole programs into our skulls at once; we should try to organize our programs in such a way that we can safely focus on one part of it at a time.

Modularity is a clunky word for the elegant idea of big things made from small things. A block of Lego is a small thing, but by assembling more than nine thousand of them, you can build one of the biggest sets Lego makes, a scale model of the Colosseum in Rome. That's modularity.

Look for it in the world, and you'll see it everywhere. A brick wall is made of hundreds of bricks. A flock of starlings, which moves as if it were a unitary organism, may be composed of hundreds or thousands of birds. Even our bodies are modular, composed of trillions of cells that are themselves modular. There's an evolutionary reason for this ubiquity: In survival of the fittest, the "fittest" is often a module that is particularly successful in reproducing itself.

If you get basics that can be switched and piece it together, that is so important.

Don't differentiate routine names solely by number. One developer wrote all his code in one big function. Then he took every 15 lines and created functions named Part1, Part2, and so on. After that, he created one high-level function that called each part.

Try to create modules that depend little on other modules. Make them detached, as business associates are, rather than attached, as Siamese twins are.

The software industry has to become better in componentization. That's a clear focus for most of the software companies. How components look, how they are maintained, the ability to maintain them separately.

developers should be able to understand and update the code of a service without knowing anything about the internals of its peer services. Services

a system where small teams of engineers are able to work productively and independently of each other, with components painstakingly and splendidly isolated from each other, instead of being complected into a giant, ugly, knotty mess.

Locality in our code is what keeps systems loosely coupled, enabling us to deliver features faster.

Make infrastructure easier to rebuild than to repair

I have absolutely no idea about space exploration. I'm a software guy. But because I'm a non-expert, I've been able to bring the software concept of modularity into the space sector, which was never done before.

We must have a better word than "prefabricated", why not "ready-made"?

Our ultimate goal is extensible programming (EP). By this, we mean the construction of hierarchies of modules, each module adding new functionality to the system.

Nothing is more disagreeable to the hacker than duplication of effort. The first and most important mental habit that people develop when they learn how to write computer programs is to generalize, generalize, generalize. To make their code as modular and flexible as possible, breaking large problems down into small subroutines that can be used over and over again in different contexts.

This is the Unix philosophy. Write programs that do one thing and do it well. Write programs to work together. Write programs that handle text streams, because that is a universal interface.

few stray bits of Lego

The way to build a complex system that works is to build it from very simple systems that work.

The right way to collaborate, I think, is to divide projects into sharply defined modules, each with a definite owner

From an epistemological perspective, a person is a uniform being who interprets the different parts of her conscious knowledge in a coherent fashion (or at least tries to do this). How do modular theories explain this search for coherence? And how do they explain necessary knowledge, which hardly can be domain-specific (Smith, 1993, p. 5)?