Candidate definitions or features of "modularity"...

A system demonstrates modularity if it contains one or more identifiable units of code or data that are:

* Unitary, in the sense that a 'module' can be readily packaged up or saved then loaded onto another machine, or effectively versioned separately from other organizations of code.

* Providing an '''interface''' to which other units of code can be written and that allow one to access the module without hand-copying code or writing explicit code to discover its implementation details. In practice, this interface is usually a set of shared names for procedures or objects.

* Swappable with an equivalent or similar functional replacement with minimal re-configuration. Fundamentally, to make one unit of code 'swappable' with another, you need to know two things: (a) how other units of code access the unit of code you're swapping out (the 'interface'), and (b) the assumptions the other code makes about what your code unit will be doing (the 'semantics'). Merely using interface could still break code by, for example, swapping a stack for a queue (same interface, different semantics). Merely using semantics would break code when the old code fails to integrate with the new code unit (so changing a stack that uses 'push' and 'pop' for one that uses 'add' and 'remove' will require an AdapterPattern).

** ''Based on my observation, I dispute that module-ness is ''solely'' about swappability, run-time packaging, and implementation-hiding, which the above implies. I propose "'''a grouping of related code'''" as the definition. Yes, it's more open-ended than the above, but so is "module" in practice. It's essentially a '''hash''' operation. Discussion below. -- top''

Some traits commonly associated with modules (but that do not define modules) include:

* Often compiled separately (in compiled languages). This is enabled because the programmers integrating a module can access it via the interface rather than via the implementation. Compiled modules will provide an ApplicationBinaryInterface that meets certain specifications. Advantages of separately compiled modules include the potential for greater startup speed and the ability to obfuscate protected intellectual property.

* Often used as '''plugins''' (PluginArchitecture) via use of a standardized interface (standardized for all groups implementing plugin modules). In this sense, modules are almost being used FirstClass polymorphic objects.

* Often used to divide '''units of work'''. Modules, due to their low external coupling, typically well defined interfaces that have low rates of change, and minimal dependency on implementation details of other modules, are ideal places to break large software projects up so that different groups can operate on different pieces.

* Understood in terms of its inputs and outputs, in particular those necessary to make modules swappable. However, this is not necessarily ''all'' the module's inputs and outputs. There are often inputs and outputs associated with the implementation that could be completely hidden to all people who wish to integrate with the module.

* Understood in terms of CouplingAndCohesion. Modules are units of high internal cohesion and well-defined external coupling through interfaces. This is what allows them to be '''swappable''' or used as '''units of work'''.

* Intended to fit an expected future ChangePattern. We may expect certain kinds of changes in the future, and building modules can act as a way to contain the impact of such changes: a kind of "shear wall".

* A group of functions or subroutines that are '''often used together'''. For instance, if a module contains routines A, B, C, and D, then the need for A tends to also increase the need for B, C, and D.

* Identified by a namespace -- at least in some programming languages, including those among the first to adopt explicit 'modules'.

* Matches one or more person's MentalIndexability. That is, units are divided by mental concepts or 'concerns' (e.g. OS compatibility, display, logging) to some degree allowed by the language. These mental concepts may or may not reflect actual external conditions or divisions. One potential downside is that internal models may not be shared by other individuals who have to work with the modules, and most languages don't support ad-hoc SeparationOfConcerns and so can't be arbitrarily 're-modularized' to support a different view. (But see SeparationOfConcerns for advanced forms of modularity.)

These are not necessarily full requirements nor mutually exclusive.

-------------------

Modularity is the ability to take a banana (or other low hanging fruit) without dragging along the whole dependency-forest.

----
'''Disputed:'''

[Disputed by who? Cite an authority or put it back together, please]

''Disputed by the contributors to this page, obviously.''

[Well, I'm a contributor, and I'm going to put it back to normal]

These got moved down here because you put them above with nothing but your own authority. Unless you're aiming to have an EditWar, I suggest you don't move them back above until the dispute has been resolved.

[Then EditWar it is, bucko! How arrogant and hypocritical to believe that your "authority" is automatically better than others. This is obviously unfair.]

''EditWar is unnecessary, especially as the entirety of this page is viewable at the twitch of a scrollbar. There used to be a tradition here of keeping disputed (the ThreadMess below is obvious evidence of a dispute) material distinct from the resolved bits, and it's standard operating procedure on WikiPedia and elsewhere. It isn't really a matter of authority or lack thereof, but the simple fact that there is a dispute, regardless of reason...''

[But which dispute viewpoint decides what is up and what is down?]

''Neither of them. Leave it for someone else to refactor, or wait until one of you agrees with the other.''

[How about this compromise: we put a summary list at the top with no "hard" dividers, and the phrase "(disputed by some)" after those items. Then the discussion section is placed below that.]

''I think keeping the disputed material here instead of moving it to W''''''hatIsModularityDiscussion is already a fair compromise.''

[Bullshit! You are just trying to elevate your opinions above mine. I'm not caving this time because it would encourage such later again. No deal!]

''I have expressed no opinions on this page other than that regarding the dispute itself. (Please take note of the IP addresses involved. By now, they should be more familiar than human names. They certainly are to me.)''

[It is relatively easy to have/use multiple IP addresses. Anyhow, I'm willing to leave this the way it is for about a month to see if we can think of a better approach by then.]

''That sounds eminently reasonable. (Sadly, I recognise the multiple IP addresses involved too, but numbers have a meaning to me that names do not. I sometimes assign interesting numbers to my students when I can't remember their names.)''

* used as a '''Unit of work''' to divide workload of staff or equipment.
** Modules are used as '''units of work''' because modules are natural places to break up work. Properly done, a group implementing one module doesn't need to know or care about the implementation of modules implemented by other groups.
*** ''You are introducing a value judgment here that we don't need at this stage. We can define a "boat" without having to get into the problem space of determining  "good boat". A unit of work may be somewhat arbitrary and still be a "module". I've seen messy modules in the past that most would still consider modules.''
*** We can define '''unit of work''' without defining '''module''' in the same sense that we can define '''flotation device''' without defining '''boat'''. Boats are used as flotation devices, and modules are used as units of work - with that much I agree. But your entire assumption that a unit of work is somehow ''automatically'' a module is not something I find to have any basis in computer science academia or practice. And the very idea that you can have "messy modules" or "leaky boats" implies that "modules" and "boats" without the extra modifier adjective are not remarkably messy or leaky (respectively).
*** ''Please clarify that last sentence. And you need to survey and document this "basis" if you wish to use it as an authority of definition. I am not obligated to accept your opinion on the matter alone. Further, non academic usage may be just as valid for establishing definitions. -- top''
*** Eh? By that logic, I am not obligated to accept your opinion alone either. Since it is only your opinion supporting this '''unit of work''' bullet point, I think I'll move it below until you "survey and document this 'basis'". And I did include "non-academic usage" (that's why I said "academia '''or practice'''", you silly and apparently illiterate boy).
*** ''Further 2: I can accept the fact that modularity is '''not Boolean'''. Something can be "more modular" than another thing. --top ''
*** Agreed, but irrelevant to whatever point you are trying (and failing) to make.
** Saying that "units of work are modules", OTOH, makes about as much logical sense as claiming that "red things are apples" simply because you're used to thinking of apples when you think of red things. Lines of code are also '''units of work''', but that doesn't make lines of code the same as '''modules'''.
** ''Modules as units of work or packaging is consistent with the term in non-IT settings.''
** I agree, modules are used as units of work (and for packaging). But it is not consistent to call just any unit of work a 'module', even in non-IT settings. See the first bullet point responding to the '''units of work''' claim. 
** ''A trait of modularity does not have to be the sole trait to help it qualify. In practice, I would say the term sort of has a "2 or more" kind of rule behind its usage. You agreed that modularity may not be discrete anyhow. Thus, your pass-or-fail assumption here appears to be a contradiction. Being a unit of work "adds to" something's "modularity score".''
** And that is what I dispute: I don't believe that "being a unit of work 'adds to' something's 'modularity score'". While it doesn't need to be a '''sole trait''', a trait must still be '''a trait of modularity''' to help it qualify. Patterns that just happen to be commonly associated with modularity because they're what 'modules' were designed to effect are not, themselves, traits '''of''' modularity. 
** ''Nobody has proposed a sure-shot way to identify such associations, including "swappability". All we have are personal anecdotes, and my personal anecdotes are just as valid as yours. You cannot turn on the rigor spigot when you want but then turn it off when it inconveniences your argument.''
** [Eh? I have suggested a way to identify such associations, below.]
** I'd suggest using a named PageAnchor or giving it its own section.
** [Do you have difficulty remembering the arguments presented on this page?]
** It probably didn't fit what I'd consider "rigor" such that I don't associate it with that concept. There is too much "soft" reasoning that it all gets lost in the pot.

* a match to a abstract mental concept - MentalIndexability 
** Unfortunately, due to CrossCuttingConcern''''''s, abstract mental concepts (such as 'mt-safety' or 'reactive programming' or 'invertible functions') often fail to make good modules. I call this 'unfortunate' because it is indicative of a MissingFeatureSmell (usually of a KeyLanguageFeature). It would be very nice if we could, in fact, modularize every programming concept. But doing so would require a programming language far beyond state of the art.
** ''Often a somewhat arbitrary division is chosen because humans cannot comprehend one giant graph blob very well without some kind of land-marks or grouping. Thus, we introduce a UsefulLie division. Just because there is no perfect grouping does not mean we live with no grouping. I've proposed database-based code repositories at the function or block level with meta-data used to classify stuff in such a way that queries can be done to see/group-by the different aspects (noun, verb, entity, utility, GUI, reporting, security, etc.) However, the languages and tools are not up to that task (so far). -- top''
** Useful or not, just because a division is arbitrary does not mean the division is a lie.
** ''AllAbstractionsLie and modules are abstractions. Therefore, modules are lies. However, that's not my main point. --top''
** AllAbstractionsLie is an abstraction, and therefore (by your admission) a lie, and therefore you are a self-admitted liar. However, that's not my main point. My second-to-main point is that you're playing silly word games again - exactly the sort of thing that prevents 'useful or interesting discussion'. Seriously, did you even attempt to understand the above sentence before you went into hand-wavy rhetoric about AllAbstractionsLie and premature generalizations made without any basis outside "your book" such as "modules are abstractions"? My main point is that modules don't need to be perfect groupings, and they can be real groupings even if arbitrary.
** ''I never intentionally play "silly word games". If you accuse me of such it will do no good because it is either a figment of your imagination, or I have no conscience control over it, doing word-game turrets. In other words, stop accusing people of shit because it just generates FlameWars instead of repairs. Note, however, sometimes we just reach the limit of English, and the questions and results can be peculiar, sounding like a word game. For example, I'd like to ask what you mean by "real grouping". --top''
** I know you don't do it '''intentionally''', but such ignorance of one's own behavior is inexcusable. And would you rather I just "repair" your words by (for example) deleting all the irrelevant bits rather than pointing them out to you? And by "real grouping" I mean that the "grouping" is not a '''lie'''. If I say "all integers strictly greater than two", it is arbitrary, but it is no less a grouping merely because it is arbitrary. That phrase, thus, describes a "real grouping". You call things 'lies' too often ("UsefulLie division" vs. "useful division"). Do you know the difference (distinction) between denotation and connotation?
** ''We are deviating from the original point of how CrossCuttingConcern''''''s make grouping difficult. We group not because any one grouping is the "ideal" grouping, but because we as humans need grouping for MentalIndexability, division of labor, etc. The computer doesn't care if we use modules or not, for an equivalent program can always be built without modules. People can and do group by various mental concepts. - top''
** '' '''Example:''' Putting database utilities in one module, reporting utilities in another, form utilities in another, graph/chart utilities in another, etc. There are indeed cross-cutting concerns in these. For example, reporting often uses the database. The division is thus not perfect. However, in a file-based world, it is the best compromise I can find. --top''
** Your whole argument seems analogous to calling red things "apples" simply because apples are (sometimes) examples of "red things". You're calling groups of related concepts "modules" simply because modules are (sometimes) used to group related concepts. CrossCuttingConcern''''''s are fine counterexamples, providing "groups of related concepts" that really don't fit the concept or features traditionally associated with "module", and that is why such concerns were mentioned above. I was being utterly literal when I said: "abstract mental concepts (such as 'mt-safety' or 'reactive programming' or 'invertible functions') often fail to make good modules". 
** ''Let me restate it: we tend to pick concepts, like the examples given, and divide *files* by those concepts in practice, and those files are usually called "modules".''
** You still haven't made a good argument that "picking concepts" is more than just coincidental. It seems, rather, that the division of code units among 'files' is more significant to the calling it 'modules'.
** ''I never used the term "coincidental". Thus, I don't know what you are referring to.''
** Regardless of whether you have used the term "coincidental" or not, you cannot reasonably claim that a given set of properties are associated with "modularity" unless you show them more than coincidental. I believe that "match to a abstract mental concept" is very much coincidental to the idea of "modularity" in the same sense that "redness" is quite coincidental to "apples". I have explained this belief.
** ''I am not here to evaluate whether mental concepts are "coincidental" or not. That is another topic altogether. I'm only saying people group code by them. Most would agree with me if we had a fair way to take surveys.'' 
** Sure. And I'm not here to discuss "abstract mental concept" or "MentalIndexability". Because, as far as I can tell, those are different topics altogether - that have nothing to do with modularity. If you're going to claim otherwise ''without'' evaluating whether or not mental concepts are coincidental to modularity, then your claims are ''unreasonable''. If you're going to make claims about surveys, then do it: hire an unbiased party survey and document this 'basis' to resolve the dispute.
** ''The other parties are not required to provide such rigor. Why am I? See also below about neuron dissection. If they are not required to perform neuron dissection to get promoted to "non-disputed", why am I?''
** You're free to not provide such rigor and attempt to allow your claims to rest solely upon your word (and reputation or authority... which really isn't counting for as much here as it would in a discussion of WhatIsTableOrientedProgramming). In such a case, I'm free to dispute it with equal weight simply by saying "I disagree," but since this WikiWiki shouldn't be a popularity contest I am obligated to provide some reasons for my disagreement to make the dispute stronger and ensure it has some basis in reason. Anyhow, things don't get "promoted" to non-disputed until one reaches a consensus among those with the authority or power to dispute. In this case, my negligible authority and power is at least equal to yours. I dispute. No promotion.
** ''Falsehood. You have not provided any decent reasons for inclusion in the non-disputed club. You only complain about others' entries.'' 
** Explanations can be provided if requested. But, technically, every statement (even the wild or insane ones) starts as non-disputed and stays that way ''until'' someone (who can make himself heard) disputes it. So it is silly to "provide reasons for inclusion in the non-disputed club", because statements always start there.
** ''This is a '''farce'''. The ones you want in non-disputed stay there unless solid rigor can bump them down and those you want down stay there unless solid rigor bumps them back up. Thus, if nobody produces solid rigor, you get your way regardless.''
** How is that a farce? A dispute needs to be reasonable. So does the response to it. I only bother disputing things I have problems with. All of these things are rational and natural. Based on your behavior here and elsewhere, you seem to want a world where you can say whatever you want on any topic you want with much handwaving and without challenge. Well, you can have such a world: get the hell off this wiki and go write yourself a blog.
** ''Most reasonable people would agree that people can and do group by mental concepts and call it a "module".''
** Most reasonable people would agree that people can and do use tools made of rubber and call these tools "hammers". That is, people would agree that these two conditions: (is a tool made of rubber) and (is called a "hammer") can and do have a non-zero overlap. But most reasonable people would not agree that "made of rubber" should be considered a primary or defining trait of "hammers", and most reasonable people would ''similarly'' not agree that "group functionality by mental concepts" should (based on your reasoning) be a primary or defining trait of WhatIsModularity. 
*** ''I don't see why the quality of the grouping trait matters. I thought we agreed elsewhere that the definition should not be testing the quality of the grouping trait (beyond being 100% arbitrary). The "hash" has to be better than random, that's all. - t''
** ''(This is not the same as agreeing that grouping by mental concepts is reasonable, for that is not what is being graded.) Thus, you are not reasonable. -- top''
** If you'd like to amend the original bullet to read: "modules are sometimes used to group functionality by mental concepts" I'd be more agreeable to it. Because that says only how they are sometimes used, rather than what they '''are'''.
** [I think it's notable that all the characteristics of modularity in the un-disputed section could, in theory, be measured via automated processes. Thus, modularity could be decided on the basis of some (perhaps arbitrary) value for a metric associated with each characteristic. E.g., the existence (or not) of an explicit namespace is a boolean value, and namespaces can be counted. Dependencies between functions can be represented as a graph and the edges counted. CouplingAndCohesion can also be represented as a graph and qualified via edge counts, and so on. However, basing identification of modularity on mental concepts requires reference to the external human agent that maintains the mental concept. To me, this suggests that the "mental concept" criterion is an amorphous characteristic of the programmer, rather than a measurable characteristic of the program. I would argue that this seriously deprecates the notion of using "mental concepts" to effectively recognise modularity, though in pragmatic terms it may be a sound justification for applying modularity. In other words, "mental concepts" are not an essential (or even identifiable) characteristic of modules, but they may be a reason to use modules.]
** I would point out that MentalIndexability could potentially be measured by somebody's ability to name the module that contains a given function, and compared with the score of randomly-grouped functions. Thus, it is "lab-able". For example, compare the subject's own grouping to that of a random computer-generated grouping and how that affects one's recall score.
** [True, and appropriate to SoftwareEngineering, but deprecated in ComputerScience. Perhaps that is the essence of this debate (aside from quibbles over the style and rigour of arguments) -- a difference in perception of WhatIsModularity from a SoftwareEngineering point of view vs a ComputerScience point of view. The latter seeks a mathematical definition rather than an empirical one.]
** This may turn into a battle over whether "common" usage should determine a definition or academic literature. 
** [Only if you choose to turn it into a battle... Better would be to recognise the variety of viewpoints -- whether "common", SoftwareEngineering, ComputerScience, or other -- and identify & elucidate them as such.]
** That was my original plan: classification flags on the list, but some bully decided to hard-divide according to their pet aspect. I would let it go, but it has happened to too many topics, so I decided make a stand this time rather than encourage poor behavior to continue.

** ''I will point out that grouping/indexing by mental concepts can be compared to a "hash", where the "reason" behind the hash does not matter just as long as the hash comes out the same each time. Thus, if I group code by how they remind me of StarWars characters, then it is possible I can still find code in their corresponding groups years later as long as the right Star Wars characters are triggered in memory. Hashes don't require "reason" for the results to do their job, only consistency. (Usually something more domain-specific or universal is chosen instead of unrelated hobbies.)''
** Thanks for clarifying what you mean by "mental indexing". But you've yet to make a good claim that this has anything to do with modularity other than "the grouping of code". It seems coincidental, as in: "Oh, I'm grouping my code into modules. And ''coincidentally'' I ''just happen'' to be grouping it by Star Wars characters."
** '''Definitions are often not decided by logic, but rather by usage'''. 
** Correct. But you need to use logic to make assertions or claims about the usage.
*** [Added later] Let me give a shot at what you might call "logic". The primary purpose of a hash is to retrieve info quickly based on a "key". Using Star Wars characters/scenes as the "key" can indeed achieve this purpose. Language garbage collection may remind one of the garbage compressor scene in Star Wars such that if they bring up that scene in their drop-down/drill-down list of SW scenes, the garbage collection part of the code would pop up. '''The hash did its job''': it provided practical utility. You may argue that the hash key is not the best choice due to staff cross-training problems, but we are talking definitions here, not "best practices". It's comparable to using a '''landmark''' to remember directions: the "funny red house" probably was not put there to help us remember directions to the doctor, but we end up using it for that because human memory is largely associative: the ugly red house reminds us to turn right because it "stands out in your mind" and is associated with an important turn. The "link" easily pops into our head so we take advantage of it. -- top
** I cannot dissect the neurons of people who use the term anymore than you do, at least not without going to jail. I already gave examples above of typical categories (forms, reports, database-related) that are often found in conjunction with the usage of term. I have not tested peoples' responses to extreme examples, like the Star Wars example, but neither have those who claim their pet traits are "non disputed". I urge you to be fair and even handed. It's a nebulous concept in practice: I'm only the messenger. --top
** So your argument is: "I can't say modularity '''isn't''' used to mean 'mental indexability'." Well, with that same logic one could argue: "I can't say modularity '''is''' used to mean 'mental indexability'."  To be fair and even handed, I need to weigh each of these arguments equally until logic, reason, and evidence is presented to better support one or the other. Since you have not met the burden of providing any such logic, reason, and evidence for your claim, I'm only left with one option in the name of fairness: to drop your claim into the 'disputed and unsubstantiated' pile.
** ''How about you "show the smart way" by "properly" justifying those in the non-disputed pile, other than "I say so". Otherwise, it would appear to be pet concept bias on your part.''
** There is no bias here: you're free to dispute those in the non-disputed pile. 
** ''But I don't want to waste my time trying to force-apply rigor to a fuzzy concept and become like you. Perhaps I have to play your dumb game to get my point across. Sigh. I don't wish to '''force an artificial rigor''' in order to talk about stuff that may not be inherently rigorous. It is often useful to explore such models as a thought exercise, but we shouldn't fall into the trap of mistaking the map for the actual territory. -- top''
** [Added later] ''I re-visited the "logic issue" above. Basically '''a module is a visible manifestation of a hash relationship'''. The hash process may seem silly or arbitrary to some, but if it allows one to translate a mental concept into a reference to a code chunk (such as a file), then it's serving its (minimal) purpose. We can "test" that modularity exists because somebody describes their grouping. If they are not around to describe their grouping method (or we cannot make a reasonable guess) and the code comments are missing or lost, then we cannot determine whether there is modularity. The code chunking would be indistinguishable from randomly-sliced code.'' - t

** I can't say I wouldn't love the ability to stick, say, all issues of delta isolation optimizations into one "module", all issues of user input in another module, and all issues of thread safety into yet another... but that would require a language that is far beyond state of the art. 
** ''Or a variation on a database.''
** I don't believe a database-based language would solve the problems either.
** [It doesn't. I've done some tentative work in this area; use of database-oriented approaches does, however, raise some interesting possibilities for simultaneously locating functionality in multiple "modules" based on categorisation, where a category and a module can be considered very roughly synonymous. It introduces as many new problems as old ones it solves, however.]
** I generally agree it creates new problems, but it has a lot of untapped or under-tapped potential. The problem is that our existing thinking and tools are geared toward linear text code. We have to learn to "think in tables", and develop new tools and techniques for managing such info in tables (TableOrientedProgramming). I believe it is a step up from linear text-code thinking, but also requires an evolution in tools and training in order to take advantage of the power of tables. It gives us potentially better control over multiple dimensions and aspect viewpoints than linear code does. TOP tends to make modularity be relative to need instead of an up-front "hard-wired" line drawn in the sand. -- top

* understood in terms of CouplingAndCohesion. Modules are units of high internal cohesion and well defined external coupling through interfaces. This is what allows them to be '''swappable''' or used as '''units of work'''.
** CouplingAndCohesion is too unrefined a concept to apply to modularity.
** ''Are you claiming that modularity is objectively "more refined" than CouplingAndCohesion concept? If not, I move to dismiss this dispute as invalid.''
** Why is that a criteria? Definitions are not necessarily about "refinement" anyhow. Otherwise, we'd have to delete "fun" from the dictionary.
** ''My criteria is that your objection is logically sensible. Frankly, you aren't making much logical sense to at one point be claiming "CouplingAndCohesion is too unrefined" in one breath and then saying "definitions are not about refinement" in another. I move to dismiss your dispute as logically invalid.''
** Again, definitions are not necessarily about logic. While logic would be nice, it is in fact not a necessary criteria for definitions.
** ''Agreed. Definitions don't need to be logical. But '''disputes''' and '''objections''' ought to be, and so should be their resolutions.''
** No real criteria has been given for disputed versus non-disputed. Until one exists, I suggest we toss that distinction altogether. Otherwise, we have a moving target.
** [Disputed vs non-disputed should be obvious:  "Disputed" is that which people disagree about.]
** Well, I dispute the C&C entry.
** ''And the grounds you provided for the dispute ("too unrefined a concept") were not rational ones, nor were they consistent with your further defense of the idea ("not about 'refinement' anyhow"). When you dispute, you really need to provide a good reason such that it can be resolved or accepted.''
** One is talking about definitions and one is not. Anyhow, describe the fucking rules for inclusion and exclusion and I will stick to them and make sure you stick to them also. You have not presented any consistent rules nor applied them consistently. If you come up with clear and consistent rules, I will abide by them. If not, we have a pending EditWar, my friend. The disputed/non-disputed is such a silly convention anyhow. I think Costin started that convention, and we should have nipped it in the bud. (At least he used a published book as the deciding factor rather than egowhims.)

** Disputed because CouplingAndCohesion are such vague and nebulous concepts. If I had my way, this would be below in the disputed pile. --top
** ''I would like to see you defend the statement: "CouplingAndCohesion are vague and nebulous concepts." It seems to me that "TopMind has a vague understanding  of CouplingAndCohesion" would be a more accurate claim. Also, it seems to me that "mental concepts" and "MentalIndexability" are far more "nebulous" than CouplingAndCohesion - can you provide a convincing argument otherwise, or will your reason for dismissing the CouplingAndCohesion bullet point be equally damning to some of your own proposals?''
** I've made my case in the CouplingAndCohesion topic. I suggest we don't let that discussion spill over into this topic if possible. -t
----
It is my observation after 20+ years of experience that ''any'' grouping of code larger than a single function or routine is called a "module" simply because there is ''no other'' common alternative (outside of "class"). There are sometimes language-specific terms, but switching these with "module" usually works. 

How about we look at it from the back side to try to resolve the disputes: what grouping of functions/routines that actually occur in practice are NOT "modules"? Objective forms of grouping include file grouping (sometimes called "include files"), and formal groupings as found in a given programming language:

 grouping_thing {
   function foo(...) {...}
   function bar(...) {...}
   subroutine blah(...) {...}
 }
-- top

I could name quite a few arbitrary groupings that aren't modules. Two static functions that just happen to be next to one another in a C file wouldn't qualify as module in any sense of the word. These 'occur in practice' all the time. 

''I thought I made it clear that there had to be some explicit grouping mechanism within the language or filing system, not just arbitrary groupings picked out by the observer. But perhaps it wasn't so clear after-all. ''

How about you look at your implicit assumptions: that there is a clear "grouping_thing" with definite insides and outsides, and a set of interface declarations that indicate how to tie relevant bits of the 'module' (and its implementation) into the larger project without re-implementing the content by hand. 

''Like I mentioned above, a file full of functions/routines is often called a "module" in practice. The "interface" was not an overriding factor, and mostly only existed at the function-to-function level. You are over-emphasizing the role of "interface" in my opinion.''

You seem to believe that emphasizing interface means I think the interface needs to be 'special', whereas when I emphasize interface I only mean to emphasize that there needs to be one - there is no such thing as a module without an interface. Shared names in a shared namespace for functions/routines makes for a reasonable interface (and, even better, match almost all historical interfaces for modules). 

''That's a rather loose usage of "interface", and more along the lines of mere "access to".''

No, "access to" is not the same. I could have "access to" a module in a manner that required me to hand-copy stuff out of the module and into my document, or that I include a great deal of specialized runtime metaprogramming in order to access it. The use of shared name based access is very much an "interface" - a declared and statically accessible way of accessing certain features of a module.
----
This is an awesome page -- thank you, whoever posted it. It describes in very few words that which I've been unable to address succinctly in past discussions.

''I started it and I'll happily take the kudos because I've had a bad week and need kudos. -- top''

{It's not awesome anymore, we turned it into a ThreadMess}

Yeah, it was truly awesome when it was just a bunch of statements from "the book" of almighty TopMind.

See, there's yet another insult from you. You have InsultTurrets.

[Do you mean InsultTurrets, InsultTourettes, or both?]

InsultTourettes aided by InsultTurrets, a dangerous combo.
----
Perhaps a module can be defined in terms of GraphTheory whereby modules are groups of nodes which separate tightly-related nodes from loosely related nodes. In other words, module boundaries are where you snip such that the link cuts (which become interfaces) are as few as possible, yet produce a reasonable number size of resulting groups. For example, in the human brain, the parts of the brain related to vision probably have far more connections between them than do parts related to vision and parts related to sound do between each other. Finding the ideal cuts in an automated way probably is a form of the "traveling salesmen" class of problems such that in practice we rely on "domain instinct". Further, no cut is perfect, just a best compromise. "Cat" in the brain is probably stored under both vision areas and sound areas. Thus, modularizing by senses (sight and sound) splits cat-related info. Thus, modularizing by senses de-modularizes by the "cat" domain noun. --top

''One could..., but why?''

Actually, I take that back. With 3D structures you have more options than with typical linear source code. In the brain, you could have a "ladder" pattern:

  V     S
  V     S
  *-Cat-*
  V     S
  V     S
  *-Dog-*
  V     S
  V     S
The "cat" grouping can closely integrate with both the vision module (V) and the sound module (S).

''Huh? I'm curious what perceived problem you're trying to fix here.''

One can modularize by visual issues, sonic issues (sound), and/or domain noun (cat). In source code often we have to sacrifice modularizing by one dimension in order to modularize by another because code is generally linear. A 3D structure like the brain is a bit more flexible. Somewhat related: SeparationAndGroupingAreArchaicConcepts.

Take an OOP model of mammals:

  class cat inherits mammal
     method speak()
       playSound("meow.wav")
     end method
     ...
  end class
  class dog inherits mammal
     method speak()
       playSound("bark.wav", repeat:=3)
     end method
     ...
  end class
Here we are modularizing by animals. Their sounds are controlled by the method "speak". We are de-modularizing by sound in order to modularize by animal "type". If we modularized by sound, then perhaps we'd have a switch/case statement with a line for each animal "type". But this would de-modularize by animal type. We are making a modularization trade-off in the above design. - t

''Are you saying you'd like to be able to (say) click a button to get a view of the source code that groups all the speak() method implementations together -- by 'mammal' or 'playSound', perhaps -- that displays the defining class name rather than being grouped by the defining class? If so, it sounds cute -- might even make an interesting PlugIn for (say) EclipseIde -- but I still don't see what problem you're trying to solve. I've maintained applications in the several hundred thousand LOC range and a need for this never came up. At least, not that couldn't be solved with conventional "search" facilities...''

Text searching may be "good enough" for most cases, but that's like arguing not to switch from COBOL because it's "good enough". And it's not just by classes or OO artifacts, but by aspects in general. See SeparationAndGroupingAreArchaicConcepts for examples. - t

''Text searching is superior to what I understand of your idea.''

* I don't see them as mutually-exclusive techniques. They each have their advantages. Text search is more error-prone in my experience. Ideally we'd have both techniques, and even abilities to mix them in a single query, such as, "Find all GUI code that satisfies the following regular expression..." (pseudo-code query for example only, not meant to imply an English query system).

Hang on -- are we talking at cross purposes here, folk? It seems to me that this discussion has mutated away from objects and towards characteristics. Organization along these lines of "animal" or "sound" looks more like relational database patterns rather than methods or object attributes. What is the actual base we are trying to define? --AnonymousDonor

I'm not sure I understand the question. Note that the topic is about modules, not necessarily OOP. I consider ''any'' chunking or grouping category to be at least a candidate for modularization. An OOP example was selected above mainly because it's a common training-book pattern that readers would more likely recognize. -t

[This topic is about modularity, not modules. 'Module' has operational definitions in various languages, similar to 'object'. One might reasonably question whether a particular decomposition into modules is actually modular.]

If the definition is defined by or depends on a particular programming language/tool, then there is no "universal" definition. It's just a fuzzy kind of notion that is clarified on a local scope per locality (a "working definition" within the tool). -T

[Being 'contextual' (i.e. specific to environment or scope) is not the same as being 'fuzzy'. Therefore, regardless of whether your conclusion is correct, your reasoning is invalid.]

Agreed, but it kicks the idea of a generic definition right in the knickers. Some of the above authors seem insistent it's clear and definite in a general sense, which I disagreed with. This tends to reinforce my relativistic viewpoint. -t

[If you admit your reasoning is invalid, then why do you believe it 'kicks' anything? And why would it reinforce your viewpoint?]

[I'm okay with relativistic viewpoints (just don't conflate 'relative' with 'fuzzy' or 'subjective'). But it would be incorrect to argue that 'modularity' is relative on the basis that 'module' is contextual. Modularity and module are very different (but obviously related) concepts. Modularity is relative, of course (otherwise we couldn't argue 'X is more modular than Y'). And modularity is even contextual (otherwise we couldn't speak of 'modularity with respect to property/feature P'). But it isn't because 'module' is contextual.]

Perhaps what I should have said is that the above implies modularity is '''arbitrary''', because each language/tool defines it how it wants to, and any commonality is at best just a nebulous notion.

[Uh, no. Languages define "module" how they want. They don't define "modularity" how they want. This entire argument about modules was off-topic from the start.]

-------
'''On "Grouping of Related Code", and defining "Related"'''

Re: "But you need to use logic to make assertions or claims about the usage [modularity can mean MentalIndexability]"

Exactly how would one go about that? We are talking about the human mind, not necessarily "logic". People are not necessarily logical in their term usage/creation, and no agreed-upon rule says usage has to be logical to create language or terms. Perhaps it would be possible to show a statistical relationship between the usage of "module" and other words or phrases. Would that satisfy your request for "logic" if such was available? - t

''Surveying the actual use would indeed qualify as evidence (for or against depending on results) of the use of modularity as meaning MentalIndexability. So would surveys of working definitions. In fact, those are the standard methods of supporting an argument that a word means something. Note that for non-technical natural language use, the results of such surveys are readily available (and the answer in this particular case is that it does not mean MentalIndexability). Technical use requires a bit more leg work, but I have never encountered it used in that manner.''

If you have no cited surveys, then we only have experience versus experience, or anecdotes versus anecdotes. I've seen the term used in different ways and see no single strong contender, by the way. The only commonality I see is that the parts in a "module" are ''somehow'' related by at least one factor. That factor(s) may correspond to something in the real world (domain), or to somebody's mental model of the domain.

''So provide an example of it being used to mean MentalIndexability. That will at least establish that someone (besides you) uses it that way.''

Sorry, I don't currently have any written linkable examples. I would note almost none of the other claims are backed with citations or links either. Most formal def's include something along the line of "a grouping of related code". However, they usually don't define "related". That comes from the WetWare.

''If you want to know what related means, look it up in a dictionary.''

There appears to be a misunderstanding here.

''You claim here that most of the definitions you've seen for modularity included something along the lines of "a grouping of related code". You then said, in a manner that indicates that you find it to be a problem, that "related" isn't defined with it. In this case, "related" is being used with its standard English usage, which you can find in a dictionary. That's why I told you to go look it up.''

My point is that "related" is often in the eye of the beholder. '''Categories are an artifact of the human mind(s);''' they are a UsefulLie. The stated relationship may appear to be very weak or useless to the domain or likely work patterns. But the person making the connections will sometimes say, "Well, it works for my mind". I don't necessarily disagree that their stated relationships exist in some form; but rather they are round-about to the point of appearing contrived, or at least unimportant. But if it fits one's ''personal model'' of the domain, no matter how strange it may appear to me, perhaps I have little room to argue other than state it may make the project difficult to hand off to future staff. How do I know my personal mental model of the domain is "better" than another, other than guessing the most common psychology/WetWare patterns in the IT population? Most of us are not trained in IT psychology, and have to guess based on experience with IT staff in general or of a particular organization. 

Let's play with an extreme example. Suppose Mike grouped subroutines/functions (subs) in alphabetical groups where all subs that start with "A" are in "module_A.code", all subs that start with "B" in "module_B.code", etc. Is this "modularity"? Most will agree it's "poor" modularity, but definitions generally cover the existence of a trait and not the quality of it. A rotten potato is still a potato[1]. Thus, are these true "modules"? -t

''If "module" is defined as "a grouping of related code", then those are modules, by that definition. If, as I have usually found to be the case, the definition of "module" requires that the relationship be functional (I.e. it has to be what the functions in the modules do that is related), then those are not modules, by those definitions. (Unless it just so happens that each letter that starts a function happens to split things up into functionally related groups.)''

* But wouldn't that limit "module" to a functional or verb-centric viewpoint, paradigm, or languages? I kind of see what you are getting at, but I don't know of a way yet to turn that into a clearer definition that is not biased toward a particular design architecture. OOP tends to group by domain nouns and less so by verbs, at least on the "file" scale. This would contradict your verb-centric suggestion.

* As another example, some propose grouping by the "engine" or language processor used, and may put all SQL, regular expressions, XML, HTML, etc. (See ScatterSqlEverywhere for examples). in one grouping of code and call it a "module" without triggering dispute over the term. The SQL or XML may be used for ("do") ''very different'' things, but the grouping by language type is sufficient to qualify for module-ness. (Again, some may rightfully disagree with the utility of such, but we are talking terms, not best practices here.)

* ''Yes it limits which groupings are considered modules. That's intentional. Those who define module that way don't want any old grouping to be a module and are usually concerned primarily with what the code does. It is therefore not surprising that they would use functionality in the definition. (And yes, it would make certain design choices non-modular. There's nothing wrong with that, or even anything wrong with using a non-modular design choice when the benefits of doing so outweigh the costs.)''

* ''As for your example, one could justify calling it a module by stating that its function is to serve SQL (XML, HTML, whatever) strings to the rest of the application. (Still wouldn't make it a good idea, in my opinion; but that's a whole 'nother argument.)''

* Okay, but one could re-word just about any grouping to shoe-horn it into its "function". You are over-stretching the function-ness in my opinion. Language, or at least English, is fairly flexible in that you can turn verbs into nouns, nouns in adjectives, and so on if you shuffle the phrasing around. Thus, the part of speech it's being used for is not necessarily a good indicator of concepts. Thus, "...is related" and "...is related by function/task" are pretty much the same thing because almost any concept can be turned into a "function/task". "Function/task" is therefore '''superfluous'''. -t

* Here is another example that one sometimes finds in the wild: Functions that happen to change often for a particular app are put together into a single "module" to make it easier to make common changes in one "place". Configuration settings for apps used by multiple organizations or commercially packaged apps are sometimes grouped this way, for example, to make it easier on the installer. When someone called that set the "configuration module", nobody would balk. The grouping here is not based on what they "do", but on their frequency or likelihood of change. (You could argue it's based on what the installer "does", which is "configuring", but again, that's shoehorning via word shuffling.)  -t

''More generally, the definitions for "module", "modularity", etc. would not (nor should they) attempt to differentiate between "good" modules and "bad" ones. So I don't really see what your point has to do with the question of what is modularity.''

I've later added that the "mental hash" has to "better than random" to qualify for my working def. Thus, I'm dismissing arbitrary chunkification, but am otherwise avoiding judging the quality of the hash (grouping criteria). Better than random can be tested by asking the creator of the criteria which module a given activity or result artifact is in. For example, "which module(s) affects how much butter goes on the food?", "Which module(s) affect the cooking time?". "Which module tells us if the bacon is burned". They should do better than random chance. -t
---------
'''Example Grouping Criteria'''

* By "function" or action, such as "generate paycheck" - typical of functional and procedural languages/paradigms

* By domain nouns (employee, store, paycheck, screen, report, etc.) - common in OOP

* By sub-variation: detail report, summary report
** by time-periods: June reports, July reports, etc.
** by location: houston-monthly-report, NY-monthly-report,...

* Alphabetically - I've seen language translation vocabulary libraries like this, for whatever reason.

* By programming language - Fortran in one set of folders, Java in another, XML in yet another

* By security - Things which are intended to be "hard to get to" are in separate folders or modules so that the boundaries are clear to security configurators.

* By work patterns, such as the "configuration in a single folder" example above. One may be configuring a diverse set of factors, but the config info is put into a single spot to make life easier for the person doing the configuration.
----------
''Footnotes''

[1] Until the point it becomes a "blob of mold"
-------
CategoryDefinition, CategoryInfoPackaging, CategorySourceManagement, CategoryDefinition