Module Major

A matrix can be stored in memory in "row-major" or "column-major" format. The difference lies in how you interpret the meanings of adjacent bytes in memory. A row-major storage format implies that adjacent bytes are (usually) other values in the same row. Likewise, a column-major storage format implies that adjacent bytes belong to the same column.

By way of analogy, we may think of software architecture as consisting of two views: a ModuleMajor? view, where fragments of code are collated by their relationship to each other (e.g., all functions that manipulate lists go into the Lists unit), and a TaskMajor view, where fragments of code are collated by their relationship to the job at hand (e.g., all functions that maintains the USS Enterprise's life support systems go into the LifeSupport?? unit).

Most languages today depend on module-major code representation. I'm currently working with Java, so I'll use it as a representative example.

In Java, all code is organized into classes. Classes contain methods, which operate on the guts of the objects instantiated from them. These methods, however, needn't be in any specific order, nor do they necessarily bear any relationship to each other, other than, "it works with my kind of object."

For example, a doubly-linked list can be utilized as a stack or a queue as well. The methods necessary for this are something like AddHead?(), RemoveHead?(), AddTail?(), and RemoveTail?(). Looking at the list module/class, we can see what is "mathematically possible" with a List object. However, there is no context as to why these methods exist. Were they added for symmetry? Were they actually used anywhere in the program? Are they there for the benefit of the customer, even if we don't use them ourselves? You can interject comments into the source to answer these questions, but that's considered an ugly hack, at best. LiterateProgramming was invented to work around this problem, for example.

Therefore...

A ModuleMajor program is written so that adjacent fragments of code are related to a singular, abstract concept, and not to any particular task you might want to employ that concept with.

Examples

Too many to mention. Virtually every program you find on freshmeat.net will be written in a language that strongly encourages or even enforces ModuleMajor program representation.

Benefits

Makes code re-use much easier, since there is a well-defined interface to the concepts that the module supports.
Has some tangible analog with reality: people are comfortable dealing with parts of stuff, and putting them together to make a whole.

Drawbacks

Makes code maintenance somewhat more difficult than it needs to be, particularly in mega-line-of-code projects. Having eight or more tabs open on an IDE is not an uncommon occurance, particularly when trying to understand how one method works. Jumping from view to view to view is very distracting and sometimes even frustrating. Imagine trying to read a novel where every paragraph ends with, "Continued on page ..."
IDEs need global context to offer their benefits. Therefore, they need to parse and internalize the state of an entire project, even if you have only one file currently open. For mega-lines-of-code projects on commercially viable hardware, this means extraordinarily long delays launching the IDE, periodic crashes (every session is a stress test!) often right in the middle of an editing session, lengthy completion times for performing even the simplest of tasks, etc.

I think ideally we should strive to do away with having to chose one physical grouping over another, as described in SeparationAndGroupingAreArchaicConcepts. But I agree it's still helpful from a human MentalIndexability perspective to group stuff, at least for variable scoping purposes. Still, I'd rather use a database to store and manage code in a large project instead of file trees. EventDrivenProgramming tends to be that way, or at least before it was polluted via MVC. (I think there's a topic on managing code in DB's around here. I will provide link if/when found.) --top

Well, I rely on MVC a lot in my coding -- it just falls out naturally from good programming practice. But, otherwise, I agree mostly with what you're saying. One of the pet projects that I'm planning on toying with over my Christmas vacation will be to explore what it would take to write an IDE that supports TaskMajor representation, while still having all the significant benefits of a refactoring browser today. Wish me luck. :) --SamuelFalvo?